MeetingActionAgent 实战用「提取 审核」双 Agent 流水线把会议记录整理成可追溯的 Markdown 会议纪要【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents导读本文以 HelloAgents 共创项目 MeetingActionAgent 的实际输出文件 example_minutes.md 为核心线索完整剖析一套「会议原文 → 结构化提取 → 独立审核 → 修正复核 → JSON 与 Markdown 双格式输出」的双 Agent 流水线。读完本文你将掌握如何用两个SimpleAgent实现职责分离的生成—审核协作如何用 Pydantic Schema 约束模型输出、如何从模型响应中稳健提取 JSON、如何用四次调用预算控制流程成本以及如何把审核通过的结构化结果渲染成可直接分享的会议纪要文档。一、先从输出看结果一份合格的会议纪要长什么样example_minutes.md是 MeetingActionAgent 针对会议原文 sample_meeting.txt 生成的最终产物它展示了该系统输出格式的完整面貌标题与元信息会议主题「新用户注册功能迭代」、会议日期2026-07-27、参会者林晓、周明、陈悦会议摘要一句话概括会议达成的共识与遗留问题已确认决策明确列出「邮箱验证码首版有效期设为 5 分钟」这类有结论的事项行动项表格每行包含任务、负责人、截止日期原文、优先级、原文证据五列其中「截止日期原文」一列专门保留原文表述便于人工核对待确认问题列出负责人未定、日期未定等遗留事项审核状态末尾以passed标记该纪要已通过独立审核。这份文档最有价值的设计是证据追溯每条行动项都附带了对应原文证据例如「林晓注册页面和表单校验由我负责7月31日前完成。」意味着纪要中每一句结论都能回到原始会议记录中验证这正是双 Agent 系统中 ReviewAgent 存在的意义——杜绝「看起来通顺但查无实据」的纪要。需要特别强调的是这份 Markdown 并非由大模型直接生成而是由普通 Python 代码根据审核通过的结构化数据渲染而来见 main.ipynb 中to_markdown函数从而避免模型对已审核内容进行二次改写引入新的错误。二、系统总览从会议原文到双格式输出的五步流水线项目 README 给出的工作流程如下会议文字记录 → MinutesAgent 生成结构化草稿 → ReviewAgent 对照原文审核 → 必要时修正并复核一次 → 保存 JSON 与 Markdown再结合 main.ipynb 的analyze_meeting函数可以还原出更细粒度的执行链路输入校验validate_transcript对会议原文做strip清洗并要求至少 20 个字符过短的输入直接抛出ValueError草稿提取MinutesAgent 依据原文提取结构化纪要草稿MeetingResult独立审核ReviewAgent 同时拿到「会议原文」和「纪要草稿」产出ReviewResult是否通过、问题清单、遗漏项、无依据项、修正建议条件修正若审核未通过且剩余调用预算 ≥ 2由 MinutesAgent 根据审核意见修正一次再由 ReviewAgent 最终复核预算不足则直接标记needs_manual_review落盘输出审核结果写回MeetingResultsave_result同时保存outputs/*.json与outputs/*.md两个文件。从架构上看这是一个「生成者—审核者」分离的流水线MinutesAgent 负责语言理解与信息抽取ReviewAgent 负责事实核查两者通过共享的 Pydantic Schema 交换结构化数据。第一版刻意不引入工具调用读取、校验、保存等 IO 全部由 Python 完成Agent 只专注于语言任务这让整个系统足够简单、可复现适合作为入门级双 Agent 协作的样板。三、用 Pydantic 定义「Agent 必须遵守的输出契约」要让两个 Agent 的输出可被程序消费第一步是定义严格的 JSON Schema。项目在 main.ipynb 中用三个 Pydantic 2 模型完成了这件事ActionItem单条行动项class ActionItem(BaseModel): task: str Field(min_length1) owner: str | None None due_date_raw: str | None None priority: Literal[高, 中, 低, 未说明] 未说明 evidence: str Field(min_length1)关键约束task和evidence不能为空字符串min_length1保证每条行动项都有任务描述和原文证据owner与due_date_raw允许为None对应「原文没有的信息不猜」这条核心规则——未知负责人显示为「未提供」priority被Literal限定为「高/中/低/未说明」四个合法值之一非法优先级例如「紧急」会被 Pydantic 直接拒绝这比依赖模型自觉规范得多。MeetingResult完整会议纪要class MeetingResult(BaseModel): title: str Field(min_length1) meeting_date: str | None None participants: list[str] Field(default_factorylist) summary: str Field(min_length1) decisions: list[str] Field(default_factorylist) action_items: list[ActionItem] Field(default_factorylist) open_questions: list[str] Field(default_factorylist) review_status: Literal[pending, passed, needs_manual_review] pending review_issues: list[str] Field(default_factorylist)review_status的三种取值对应审核生命周期pending尚未审核、passed通过、needs_manual_review需人工复核而example_minutes.md末尾展示的passed正是首轮审核即通过的结果。ReviewResult审核结论class ReviewResult(BaseModel): passed: bool issues: list[str] Field(default_factorylist) missing_items: list[str] Field(default_factorylist) unsupported_items: list[str] Field(default_factorylist) revision_advice: list[str] Field(default_factorylist)issues是汇总问题missing_items记录原文有而草稿遗漏的信息unsupported_items记录草稿中有但原文不支持的「编造」内容revision_advice为修正提供方向。analyze_meeting在判定未通过时会把这三类问题合并写入review_issues字段。四、Schema 如何传递给 AgentJSON Schema 驱动的提示词定义模型后还需把 Schema「翻译」给模型。项目中的run_structured函数做了这件事def run_structured(agent, prompt, model_type, budget): schema json.dumps(model_type.model_json_schema(), ensure_asciiFalse) full_prompt f{prompt}\n\n必须遵循以下 JSON Schema\n{schema} raw_response budget.run(agent, full_prompt) try: return parse_model_response(raw_response, model_type) except ValueError as error: # ... 格式修复逻辑它通过model_type.model_json_schema()自动把 Pydantic 模型序列化为 JSON Schema拼接到用户提示词末尾要求模型「只返回符合 Schema 的 JSON不要返回 Markdown 或额外解释」。这样提示词与数据结构由同一份 Python 定义驱动Schema 变更时无需同步修改多处提示词文本。五、从模型响应到结构化对象稳健的 JSON 提取与一次格式修复模型输出往往并不严格遵守「只返回 JSON」的约定可能把 JSON 包裹在 Markdown 代码围栏中或前后附加解释。为此项目实现了extract_json_objectdef extract_json_object(text: str) - dict: start text.find({) end text.rfind(}) if start -1 or end -1 or end start: raise ValueError(模型响应中没有完整的 JSON 对象) return json.loads(text[start : end 1])策略是取第一个{到最后一个}之间的子串再交给json.loads可同时容忍代码围栏、前后缀说明文字等常见噪声parse_model_response再调用model_type.model_validate(...)完成 Pydantic 校验。Notebook 自检中专门验证了「包裹在 json 代码围栏中」的场景仍能正确解析。若首次解析失败run_structured允许请求一次「格式修复」把校验错误、原始响应和目标 Schema 一并回传给模型要求「不改变内容含义只修复格式」。需要注意的是这次修复调用同样计入四次调用预算防止无限重试。六、双 Agent 分工与提示词设计提取者与审核者的边界MinutesAgent严谨的信息提取者MINUTES_SYSTEM_PROMPT 你是严谨的中文会议纪要提取专家。 只使用会议原文明确支持的信息不得补充常识或猜测。 严格区分讨论、建议和已确认决策。 每个行动项必须保留一段原文证据未知负责人、会议日期或截止日期必须为 null。 只返回符合用户给定 Schema 的 JSON不要返回 Markdown 或额外解释。三个要点只提取原文支持的信息对抗幻觉、区分讨论/建议/决策防止把「可以考虑下个月上线」这种建议误记为决策、未知值必须为 null与 Pydantic 的可空字段呼应。ReviewAgent独立的审核员REVIEW_SYSTEM_PROMPT 你是独立的会议纪要审核员。 必须逐项对照会议原文和纪要草稿检查遗漏、编造、模糊行动项和日期冲突。 不能因为文字通顺就判定通过也不能使用外部信息。 只返回符合用户给定 Schema 的 JSON不要返回 Markdown 或额外解释。审核提示词把「会议原文」与「纪要草稿」同时放入用户消息make_review_prompt函数强制审核员回到原文逐项核对。边界案例 edge_case_meeting.txt 恰好覆盖了这些审查点王宁可以考虑下个月上线但这只是一个初步想法建议 ≠ 决策、赵可测试环境需要有人确认目前还没有负责人任务无负责人、孙然会议前的记录写产品文档周三完成但今天讨论时又有人说周五完成日期冲突。这种「提取与审核分离」的思路在 HelloAgents 教材中同样有对应范式——Reflection.py 展示了「生成—反思—优化」的迭代结构而本项目将其落地为「提取—审核—修正」的双 Agent 协作审核意见issues/missing_items/unsupported_items即充当反思信号。七、四次调用预算把不确定性关进笼子LLM 调用有成本和不确定性项目通过CallBudget类把整个流程的模型调用次数硬性限制为四次class CallBudget: def __init__(self, maximum: int 4) - None: self.maximum maximum self.used 0 property def remaining(self) - int: return self.maximum - self.used def run(self, agent, prompt: str) - str: if self.remaining 0: raise RuntimeError(已达到四次模型调用上限) self.used 1 return agent.run(prompt)预算的分配逻辑清晰理想路径下「提取 审核」仅消耗 2 次调用example_minutes.md 对应的真实运行正是 2 次若审核未通过且剩余预算 ≥ 2则执行「修正 最终复核」各一次凑满 4 次若审核未通过但预算不足 2 次例如中间发生过 JSON 格式修复则直接标记needs_manual_review交由人工兜底。这样既允许一次「知错就改」的机会又保证流程在任何情况下都能在有限成本内收敛不会出现死循环。八、Markdown 渲染结构化数据到可读文档的确定性转换example_minutes.md的每一行都有对应的渲染代码to_markdown函数核心是markdown_cell对可空字段的统一处理def markdown_cell(value: str | None) - str: if not value: return 未提供 return value.replace(|, \\|).replace(\n, )None未知统一渲染为「未提供」与example_minutes.md中「未提供 / 未说明」的呈现完全对应对值中的|和换行做转义防止内容破坏 Markdown 表格结构行动项为空时渲染占位行| 无 | 未提供 | 未说明 | 未提供 |待确认问题为空时渲染- 无保证文档结构完整。此外save_result把同一份MeetingResult同时导出为 JSONmodel_dump_json(indent2)和 MarkdownJSON 版本见 example_result.json面向程序消费其中due_date_raw: null、owner: null等字段清晰表达了信息缺失Markdown 版本面向人阅读与分享。两个文件由同一份审核过的数据驱动天然保持一致不会出现「JSON 和文档对不上」的问题。九、六组离线自检不调用模型也能守住质量底线Notebook 的最后一节提供了完全不依赖模型的 6 组自检见 main.ipynb 的「结构与编排自检」单元格覆盖JSON 围栏解析将example_result.json内容包进 json 代码围栏后parse_model_response仍能正确解析出标题字段核对校验meeting_date与最后一条行动项owner is None等关键字段空行动项构造无行动项的MeetingResult断言 Markdown 渲染结果包含| 无 |占位过短输入validate_transcript(太短)应抛ValueError非法优先级priority紧急应被 Pydantic 的ValidationError拒绝渲染一致性to_markdown(expected_result)的输出必须与仓库中跟踪的example_minutes.md逐字节一致——这保证了本文开头展示的文档确实由该渲染器生成任何渲染逻辑改动都会让自检失败。这套自检把「能跑」与「跑得对」区分开来即使没有真实模型也能验证数据结构、解析函数与渲染器的正确性非常适合作为 Agent 项目的回归测试基线。十、环境配置与运行从零跑通完整流程依赖清单requirements.txt 明确了运行环境hello-agents0.2.9 openai1.109,2 pydantic2.12,3 python-dotenv1.2,2 huggingface-hub1.20,2 # hello-agents 0.2.9 导入时需要 jupyterlab4.4,5 ipykernel6.30,8配置模型复制.env.example为.env填写任一 OpenAI-compatible 模型服务LLM_MODEL_IDyour-model-id LLM_API_KEYyour-api-key LLM_BASE_URLhttps://your-provider.example/v1这三项环境变量与 HelloAgents 的HelloAgentsLLM客户端设计一致参考 llm_client.py 的实现客户端优先使用构造函数传入参数否则从环境变量读取LLM_MODEL_ID、LLM_API_KEY、LLM_BASE_URL可选LLM_TIMEOUT默认 60 秒三者缺一即抛错。.env已被 Git 忽略禁止提交真实密钥。运行方式在Henry2513-MeetingActionAgent项目目录下启动 Jupyterjupyter lab打开main.ipynb确认内核使用当前项目的.venv从上到下运行即可。Notebook 会直接调用真实模型分析 sample_meeting.txt并输出模型调用次数、审核状态与保存的文件名。README 明确提示必须从项目目录启动 JupyterNotebook 不兼容其他工作目录因为PROJECT_ROOT Path.cwd()依赖当前工作目录定位data/与outputs/。实际运行记录README「性能评估」一节给出了提交前的一次真实运行结果共调用模型 2 次最终审核状态为passed提取 4 个行动项和 1 个已确认决策4 条行动项证据均能在会议原文中找到6 组离线自检全部通过。这正是example_minutes.md的诞生过程——一次首轮审核即通过的典型路径。十一、已知边界与后续演进项目 README 如实列出了当前限制理解这些边界有助于判断适用场景只处理文字记录不处理录音或实时会议不搜索互联网不使用数据库、RAG、MCP 或长期记忆第一版刻意保持「双 Agent、无工具调用」的极简形态LLM 输出存在不确定性needs_manual_review的结果必须人工确认不能直接当作事实使用示例数据均为虚构内容不应输入敏感会议数据。未来计划包括增加日期标准化工具同时保留原文日期用于核对、支持连续处理多份会议记录并分别保存结果。结语以「输出即验证」的思维构建 Agent 流水线回顾example_minutes.md这一份小小的输出文件背后是一条完整且可复现的工程链路Pydantic 定义输出契约 → Schema 注入提示词 → 稳健的 JSON 提取与格式修复 → 提取/审核双 Agent 职责分离 → 四次调用预算兜底 → 确定性 Markdown 渲染 → 六组离线自检护航。它示范了一个值得借鉴的 Agent 设计原则让程序处理确定性的数据流校验、解析、渲染、保存让模型只处理不确定性的语言理解提取、审核、修正并以「每一条结论都可追溯到原文证据」作为质量底线。对于想入门双 Agent 协作或 HelloAgents 框架的开发者这是一个规模适中、结构清晰、可立即复现的参考实现。【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MeetingActionAgent 实战：用「提取 + 审核」双 Agent 流水线把会议记录整理成可追溯的 Markdown 会议纪要
MeetingActionAgent 实战用「提取 审核」双 Agent 流水线把会议记录整理成可追溯的 Markdown 会议纪要【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents导读本文以 HelloAgents 共创项目 MeetingActionAgent 的实际输出文件 example_minutes.md 为核心线索完整剖析一套「会议原文 → 结构化提取 → 独立审核 → 修正复核 → JSON 与 Markdown 双格式输出」的双 Agent 流水线。读完本文你将掌握如何用两个SimpleAgent实现职责分离的生成—审核协作如何用 Pydantic Schema 约束模型输出、如何从模型响应中稳健提取 JSON、如何用四次调用预算控制流程成本以及如何把审核通过的结构化结果渲染成可直接分享的会议纪要文档。一、先从输出看结果一份合格的会议纪要长什么样example_minutes.md是 MeetingActionAgent 针对会议原文 sample_meeting.txt 生成的最终产物它展示了该系统输出格式的完整面貌标题与元信息会议主题「新用户注册功能迭代」、会议日期2026-07-27、参会者林晓、周明、陈悦会议摘要一句话概括会议达成的共识与遗留问题已确认决策明确列出「邮箱验证码首版有效期设为 5 分钟」这类有结论的事项行动项表格每行包含任务、负责人、截止日期原文、优先级、原文证据五列其中「截止日期原文」一列专门保留原文表述便于人工核对待确认问题列出负责人未定、日期未定等遗留事项审核状态末尾以passed标记该纪要已通过独立审核。这份文档最有价值的设计是证据追溯每条行动项都附带了对应原文证据例如「林晓注册页面和表单校验由我负责7月31日前完成。」意味着纪要中每一句结论都能回到原始会议记录中验证这正是双 Agent 系统中 ReviewAgent 存在的意义——杜绝「看起来通顺但查无实据」的纪要。需要特别强调的是这份 Markdown 并非由大模型直接生成而是由普通 Python 代码根据审核通过的结构化数据渲染而来见 main.ipynb 中to_markdown函数从而避免模型对已审核内容进行二次改写引入新的错误。二、系统总览从会议原文到双格式输出的五步流水线项目 README 给出的工作流程如下会议文字记录 → MinutesAgent 生成结构化草稿 → ReviewAgent 对照原文审核 → 必要时修正并复核一次 → 保存 JSON 与 Markdown再结合 main.ipynb 的analyze_meeting函数可以还原出更细粒度的执行链路输入校验validate_transcript对会议原文做strip清洗并要求至少 20 个字符过短的输入直接抛出ValueError草稿提取MinutesAgent 依据原文提取结构化纪要草稿MeetingResult独立审核ReviewAgent 同时拿到「会议原文」和「纪要草稿」产出ReviewResult是否通过、问题清单、遗漏项、无依据项、修正建议条件修正若审核未通过且剩余调用预算 ≥ 2由 MinutesAgent 根据审核意见修正一次再由 ReviewAgent 最终复核预算不足则直接标记needs_manual_review落盘输出审核结果写回MeetingResultsave_result同时保存outputs/*.json与outputs/*.md两个文件。从架构上看这是一个「生成者—审核者」分离的流水线MinutesAgent 负责语言理解与信息抽取ReviewAgent 负责事实核查两者通过共享的 Pydantic Schema 交换结构化数据。第一版刻意不引入工具调用读取、校验、保存等 IO 全部由 Python 完成Agent 只专注于语言任务这让整个系统足够简单、可复现适合作为入门级双 Agent 协作的样板。三、用 Pydantic 定义「Agent 必须遵守的输出契约」要让两个 Agent 的输出可被程序消费第一步是定义严格的 JSON Schema。项目在 main.ipynb 中用三个 Pydantic 2 模型完成了这件事ActionItem单条行动项class ActionItem(BaseModel): task: str Field(min_length1) owner: str | None None due_date_raw: str | None None priority: Literal[高, 中, 低, 未说明] 未说明 evidence: str Field(min_length1)关键约束task和evidence不能为空字符串min_length1保证每条行动项都有任务描述和原文证据owner与due_date_raw允许为None对应「原文没有的信息不猜」这条核心规则——未知负责人显示为「未提供」priority被Literal限定为「高/中/低/未说明」四个合法值之一非法优先级例如「紧急」会被 Pydantic 直接拒绝这比依赖模型自觉规范得多。MeetingResult完整会议纪要class MeetingResult(BaseModel): title: str Field(min_length1) meeting_date: str | None None participants: list[str] Field(default_factorylist) summary: str Field(min_length1) decisions: list[str] Field(default_factorylist) action_items: list[ActionItem] Field(default_factorylist) open_questions: list[str] Field(default_factorylist) review_status: Literal[pending, passed, needs_manual_review] pending review_issues: list[str] Field(default_factorylist)review_status的三种取值对应审核生命周期pending尚未审核、passed通过、needs_manual_review需人工复核而example_minutes.md末尾展示的passed正是首轮审核即通过的结果。ReviewResult审核结论class ReviewResult(BaseModel): passed: bool issues: list[str] Field(default_factorylist) missing_items: list[str] Field(default_factorylist) unsupported_items: list[str] Field(default_factorylist) revision_advice: list[str] Field(default_factorylist)issues是汇总问题missing_items记录原文有而草稿遗漏的信息unsupported_items记录草稿中有但原文不支持的「编造」内容revision_advice为修正提供方向。analyze_meeting在判定未通过时会把这三类问题合并写入review_issues字段。四、Schema 如何传递给 AgentJSON Schema 驱动的提示词定义模型后还需把 Schema「翻译」给模型。项目中的run_structured函数做了这件事def run_structured(agent, prompt, model_type, budget): schema json.dumps(model_type.model_json_schema(), ensure_asciiFalse) full_prompt f{prompt}\n\n必须遵循以下 JSON Schema\n{schema} raw_response budget.run(agent, full_prompt) try: return parse_model_response(raw_response, model_type) except ValueError as error: # ... 格式修复逻辑它通过model_type.model_json_schema()自动把 Pydantic 模型序列化为 JSON Schema拼接到用户提示词末尾要求模型「只返回符合 Schema 的 JSON不要返回 Markdown 或额外解释」。这样提示词与数据结构由同一份 Python 定义驱动Schema 变更时无需同步修改多处提示词文本。五、从模型响应到结构化对象稳健的 JSON 提取与一次格式修复模型输出往往并不严格遵守「只返回 JSON」的约定可能把 JSON 包裹在 Markdown 代码围栏中或前后附加解释。为此项目实现了extract_json_objectdef extract_json_object(text: str) - dict: start text.find({) end text.rfind(}) if start -1 or end -1 or end start: raise ValueError(模型响应中没有完整的 JSON 对象) return json.loads(text[start : end 1])策略是取第一个{到最后一个}之间的子串再交给json.loads可同时容忍代码围栏、前后缀说明文字等常见噪声parse_model_response再调用model_type.model_validate(...)完成 Pydantic 校验。Notebook 自检中专门验证了「包裹在 json 代码围栏中」的场景仍能正确解析。若首次解析失败run_structured允许请求一次「格式修复」把校验错误、原始响应和目标 Schema 一并回传给模型要求「不改变内容含义只修复格式」。需要注意的是这次修复调用同样计入四次调用预算防止无限重试。六、双 Agent 分工与提示词设计提取者与审核者的边界MinutesAgent严谨的信息提取者MINUTES_SYSTEM_PROMPT 你是严谨的中文会议纪要提取专家。 只使用会议原文明确支持的信息不得补充常识或猜测。 严格区分讨论、建议和已确认决策。 每个行动项必须保留一段原文证据未知负责人、会议日期或截止日期必须为 null。 只返回符合用户给定 Schema 的 JSON不要返回 Markdown 或额外解释。三个要点只提取原文支持的信息对抗幻觉、区分讨论/建议/决策防止把「可以考虑下个月上线」这种建议误记为决策、未知值必须为 null与 Pydantic 的可空字段呼应。ReviewAgent独立的审核员REVIEW_SYSTEM_PROMPT 你是独立的会议纪要审核员。 必须逐项对照会议原文和纪要草稿检查遗漏、编造、模糊行动项和日期冲突。 不能因为文字通顺就判定通过也不能使用外部信息。 只返回符合用户给定 Schema 的 JSON不要返回 Markdown 或额外解释。审核提示词把「会议原文」与「纪要草稿」同时放入用户消息make_review_prompt函数强制审核员回到原文逐项核对。边界案例 edge_case_meeting.txt 恰好覆盖了这些审查点王宁可以考虑下个月上线但这只是一个初步想法建议 ≠ 决策、赵可测试环境需要有人确认目前还没有负责人任务无负责人、孙然会议前的记录写产品文档周三完成但今天讨论时又有人说周五完成日期冲突。这种「提取与审核分离」的思路在 HelloAgents 教材中同样有对应范式——Reflection.py 展示了「生成—反思—优化」的迭代结构而本项目将其落地为「提取—审核—修正」的双 Agent 协作审核意见issues/missing_items/unsupported_items即充当反思信号。七、四次调用预算把不确定性关进笼子LLM 调用有成本和不确定性项目通过CallBudget类把整个流程的模型调用次数硬性限制为四次class CallBudget: def __init__(self, maximum: int 4) - None: self.maximum maximum self.used 0 property def remaining(self) - int: return self.maximum - self.used def run(self, agent, prompt: str) - str: if self.remaining 0: raise RuntimeError(已达到四次模型调用上限) self.used 1 return agent.run(prompt)预算的分配逻辑清晰理想路径下「提取 审核」仅消耗 2 次调用example_minutes.md 对应的真实运行正是 2 次若审核未通过且剩余预算 ≥ 2则执行「修正 最终复核」各一次凑满 4 次若审核未通过但预算不足 2 次例如中间发生过 JSON 格式修复则直接标记needs_manual_review交由人工兜底。这样既允许一次「知错就改」的机会又保证流程在任何情况下都能在有限成本内收敛不会出现死循环。八、Markdown 渲染结构化数据到可读文档的确定性转换example_minutes.md的每一行都有对应的渲染代码to_markdown函数核心是markdown_cell对可空字段的统一处理def markdown_cell(value: str | None) - str: if not value: return 未提供 return value.replace(|, \\|).replace(\n, )None未知统一渲染为「未提供」与example_minutes.md中「未提供 / 未说明」的呈现完全对应对值中的|和换行做转义防止内容破坏 Markdown 表格结构行动项为空时渲染占位行| 无 | 未提供 | 未说明 | 未提供 |待确认问题为空时渲染- 无保证文档结构完整。此外save_result把同一份MeetingResult同时导出为 JSONmodel_dump_json(indent2)和 MarkdownJSON 版本见 example_result.json面向程序消费其中due_date_raw: null、owner: null等字段清晰表达了信息缺失Markdown 版本面向人阅读与分享。两个文件由同一份审核过的数据驱动天然保持一致不会出现「JSON 和文档对不上」的问题。九、六组离线自检不调用模型也能守住质量底线Notebook 的最后一节提供了完全不依赖模型的 6 组自检见 main.ipynb 的「结构与编排自检」单元格覆盖JSON 围栏解析将example_result.json内容包进 json 代码围栏后parse_model_response仍能正确解析出标题字段核对校验meeting_date与最后一条行动项owner is None等关键字段空行动项构造无行动项的MeetingResult断言 Markdown 渲染结果包含| 无 |占位过短输入validate_transcript(太短)应抛ValueError非法优先级priority紧急应被 Pydantic 的ValidationError拒绝渲染一致性to_markdown(expected_result)的输出必须与仓库中跟踪的example_minutes.md逐字节一致——这保证了本文开头展示的文档确实由该渲染器生成任何渲染逻辑改动都会让自检失败。这套自检把「能跑」与「跑得对」区分开来即使没有真实模型也能验证数据结构、解析函数与渲染器的正确性非常适合作为 Agent 项目的回归测试基线。十、环境配置与运行从零跑通完整流程依赖清单requirements.txt 明确了运行环境hello-agents0.2.9 openai1.109,2 pydantic2.12,3 python-dotenv1.2,2 huggingface-hub1.20,2 # hello-agents 0.2.9 导入时需要 jupyterlab4.4,5 ipykernel6.30,8配置模型复制.env.example为.env填写任一 OpenAI-compatible 模型服务LLM_MODEL_IDyour-model-id LLM_API_KEYyour-api-key LLM_BASE_URLhttps://your-provider.example/v1这三项环境变量与 HelloAgents 的HelloAgentsLLM客户端设计一致参考 llm_client.py 的实现客户端优先使用构造函数传入参数否则从环境变量读取LLM_MODEL_ID、LLM_API_KEY、LLM_BASE_URL可选LLM_TIMEOUT默认 60 秒三者缺一即抛错。.env已被 Git 忽略禁止提交真实密钥。运行方式在Henry2513-MeetingActionAgent项目目录下启动 Jupyterjupyter lab打开main.ipynb确认内核使用当前项目的.venv从上到下运行即可。Notebook 会直接调用真实模型分析 sample_meeting.txt并输出模型调用次数、审核状态与保存的文件名。README 明确提示必须从项目目录启动 JupyterNotebook 不兼容其他工作目录因为PROJECT_ROOT Path.cwd()依赖当前工作目录定位data/与outputs/。实际运行记录README「性能评估」一节给出了提交前的一次真实运行结果共调用模型 2 次最终审核状态为passed提取 4 个行动项和 1 个已确认决策4 条行动项证据均能在会议原文中找到6 组离线自检全部通过。这正是example_minutes.md的诞生过程——一次首轮审核即通过的典型路径。十一、已知边界与后续演进项目 README 如实列出了当前限制理解这些边界有助于判断适用场景只处理文字记录不处理录音或实时会议不搜索互联网不使用数据库、RAG、MCP 或长期记忆第一版刻意保持「双 Agent、无工具调用」的极简形态LLM 输出存在不确定性needs_manual_review的结果必须人工确认不能直接当作事实使用示例数据均为虚构内容不应输入敏感会议数据。未来计划包括增加日期标准化工具同时保留原文日期用于核对、支持连续处理多份会议记录并分别保存结果。结语以「输出即验证」的思维构建 Agent 流水线回顾example_minutes.md这一份小小的输出文件背后是一条完整且可复现的工程链路Pydantic 定义输出契约 → Schema 注入提示词 → 稳健的 JSON 提取与格式修复 → 提取/审核双 Agent 职责分离 → 四次调用预算兜底 → 确定性 Markdown 渲染 → 六组离线自检护航。它示范了一个值得借鉴的 Agent 设计原则让程序处理确定性的数据流校验、解析、渲染、保存让模型只处理不确定性的语言理解提取、审核、修正并以「每一条结论都可追溯到原文证据」作为质量底线。对于想入门双 Agent 协作或 HelloAgents 框架的开发者这是一个规模适中、结构清晰、可立即复现的参考实现。【免费下载链接】hello-agents 《从零开始构建智能体》——从零开始的智能体原理与实践教程项目地址: https://gitcode.com/GitHub_Trending/he/hello-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考