企业官网建设流程全解析

• 示例工程
• 人工智能

本篇文章以开源仓库 500-AI-Agents-Projects 中 agents/10-meeting-notes-agent 为对象，完整讲解 Meeting Notes Agent 的安装配置、命令行用法、输出格式，以及其基于 LangChain 调用 GPT-4o-mini 将自由会议转录文本转化为结构化纪要（摘要、决策、行动项、阻塞项、后续会议）的实现原理。读完本文，你将掌握一个可直接运行的会议纪要自动化方案，并理解其提示词设计、JSON 解析、Markdown 渲染与文件落盘的关键实现细节。

一、项目定位与整体架构

Meeting Notes Agent 是 500-AI-Agents-Projects 仓库中 agents 目录下 21 个可独立运行 AI Agent 中的第 10 号，在 agents/README.md 的 Agent 索引中被标注为 Productivity（生产力）行业、难度两星（⭐⭐）。它的核心任务在 README.md 中一句话概括：

Converts meeting transcripts into structured notes with summary, action items, decisions, and follow-ups.

即：把一段自由口语化的会议转录文本，自动转换为包含摘要、行动项、决策、后续跟进的结构化会议纪要。其技术选型非常轻量：

整个 Agent 是单文件实现（agent.py，约 150 行），采用"提示词约束输出 JSON → 解析 JSON → 渲染 Markdown → 写文件"的经典流水线，不依赖任何额外的编排框架，非常适合作为 LangChain 单模型 Agent 的入门范例。

从 metadata.yaml 可以看到它的元数据：framework: langchain、llm: gpt-4o-mini、tags: [productivity, meetings, summarization, action-items]，清晰地标明了其所属行业与功能标签。

二、环境准备与安装配置

2.1 依赖安装

运行环境依赖记录在 requirements.txt 中，共四个包：

langchain==0.3.0 langchain-core==0.3.0 langchain-openai==0.2.0 python-dotenv==1.0.1

按照 README.md 的 Setup 章节执行安装：

pip install -r requirements.txt

要点说明：

• langchain-core==0.3.0提供SystemMessage、HumanMessage等消息抽象，供本 Agent 构造对话上下文；
• langchain-openai==0.2.0提供ChatOpenAI客户端，负责真正调用 GPT-4o-mini；
• python-dotenv==1.0.1用于加载.env中的 API Key。

2.2 API Key 配置

安装完成后，复制环境变量模板：

cp .env.example .env

.env.example 内容只有一个键：

OPENAI_API_KEY=your_openai_api_key_here

将your_openai_api_key_here替换为你自己的 OpenAI API Key 即可。在 agent.py 中通过load_dotenv()在脚本启动时自动加载.env文件，随后ChatOpenAI会从环境中读取该 Key。注意：本 Agent 依赖 OpenAI 官方 API，运行前需确保网络可达且账户可用，这是使用前提。

三、运行方式：四种命令行用法

README.md 的 Run 章节给出了完整的命令行用法，全部由 agent.py 的main()函数通过argparse实现。核心参数有两个：

方式一：使用内置示例转录文本（零参数）

python agent.py

不传任何参数时，Agent 自动回退到内置的SAMPLE_TRANSCRIPT（一段关于"Q4 产品路线图"的模拟会议对话，见 agent.py），适合首次运行快速验证链路是否打通。

方式二：传入本地转录文件

python agent.py --transcript meeting_transcript.txt

从meeting_transcript.txt读取会议转录内容并生成纪要，这是最常见的真实使用方式。

方式三：内联文本

python agent.py --text "Alice: Let's ship by Friday. Bob: I need 2 more days for testing..."

无需文件，直接把带说话人前缀的对话文本作为参数传入，适合快速测试或命令行管道场景。

方式四：自定义输出路径

python agent.py --transcript meeting_transcript.txt --output sprint_notes.md

将结果写入sprint_notes.md，而不是默认的meeting_notes.md，便于归档到指定目录。

参数互斥逻辑

从源码可以看到，--transcript与--text被放入argparse的互斥组（parser.add_mutually_exclusive_group()，见 agent.py），两者不可同时使用。三路输入优先级为：--transcript文件 >--text内联 > 内置示例，见 agent.py。

四、输出内容与文件落盘规则

4.1 生成的纪要包含什么

README 的 Output 章节明确列出了输出 Markdown 的结构，同时 format_notes() 给出了字段级实现。一份典型的meeting_notes.md长这样：

# Q4 Product Roadmap Planning **Date:** 2026-09-29 | **Duration:** 30 minutes **Participants:** Sarah, John, Mike, Lisa ## Summary …… ## Key Decisions - Freeze feature set by November 15th - Cut social login from this release, move to Q1 backlog ## Action Items - [ ] **Escalate PaymentCo API docs** — Owner: John | Due: end of today - [ ] **Continue payment integration** — Owner: Lisa | Due: November 10th - [ ] **Start testing** — Owner: Mike | Due: November 11th ## Blockers - Payment provider API docs not yet received **Next Meeting:** Same time next week, November 10th

对应 README.md 列出的五大要素：

• Executive summary（执行摘要）：2～3 句会议核心总结；
• Key decisions（关键决策）：会议中拍板的事项清单；
• Action items with owners and due dates（带负责人与截止日期的行动项）：以- [ ]任务清单（task/owner/due）形式呈现；
• Blockers（阻塞项）：阻碍进展的问题；
• Next meeting time（下次会议时间）。

此外源码还渲染了标题、日期、时长与参与者行，形成完整的纪要头信息。

4.2 文件命名与防覆盖机制

一个值得注意的设计细节在 agent.py：

• 默认输出文件为meeting_notes.md；
• 若该文件已经存在且本次使用的是默认输出路径，Agent 会自动生成带时间戳的新文件meeting_notes_YYYYMMDD_HHMMSS.md，避免覆盖历史纪要；
• 若用户通过--output显式指定了其他路径，则直接写入该路径（不做时间戳处理）。

这与 README 中 "If that file already exists, the agent writes a timestamped file instead" 的描述完全一致。运行结束后，终端会同时打印格式化纪要全文（以=分隔线包裹）和✅ Saved to: <路径>的落盘提示。

五、源码级原理：提示词、JSON 解析与渲染

5.1 结构化输出的关键：NOTES_PROMPT

Meeting Notes Agent 的核心技巧是用提示词约束模型输出合法 JSON。NOTES_PROMPT 定义了完整的 JSON Schema，包含 11 个字段：

{ "meeting_title": "inferred title", "date": "today or mentioned date", "participants": ["name1", "name2"], "duration_estimate": "X minutes", "summary": "2-3 sentence executive summary", "key_decisions": ["decision 1", "decision 2"], "action_items": [ {"task": "description", "owner": "person name or TBD", "due": "date or timeframe or TBD"} ], "discussion_topics": ["topic 1", "topic 2"], "blockers": ["blocker 1 or none"], "next_meeting": "scheduled time or TBD", "follow_up_questions": ["question needing resolution"] }

设计要点：

• 每个字段都附带取值约定（如summary限定为 2～3 句、due允许TBD），降低模型自由发挥的空间；
• 提示词末尾的Return only valid JSON.是约束纯 JSON 输出的关键指令；
• 与 README 列出的五大输出要素相比，提示词层还额外要求了meeting_title、participants、duration_estimate、discussion_topics、follow_up_questions等字段——模型一次抽取的字段比最终渲染展示的更多，信息冗余设计保证了渲染时可按需取舍。

5.2 调用链路：零温度推理

generate_meeting_notes() 是核心推理函数，完整调用链为：

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) messages = [ SystemMessage(content=NOTES_PROMPT), HumanMessage(content=f"Meeting transcript:\n\n{transcript}"), ] response = llm.invoke(messages) return parse_json_response(response.content)

三个关键工程决策：

1. temperature=0：会议纪要属于确定性任务，零温度让模型输出尽可能稳定、可复现，避免每次运行摘要措辞漂移；
2. System/ Human 双层消息：系统消息固定携带 JSON Schema 约束，用户消息动态注入转录文本，符合 LangChain 的消息模型最佳实践；
3. 结构化抽取而非自由生成：模型只负责抽取结构化数据，Markdown 排版完全由本地代码完成，保证输出格式 100% 一致。

5.3 健壮的 JSON 解析

由于 GPT-4o-mini 输出偶尔会带 ```json 代码围栏，parse_json_response() 做了两层防御：

def parse_json_response(text: str) -> dict: cleaned = text.strip() if cleaned.startswith("```"): cleaned = re.sub(r"^```(?:json)?\s*", "", cleaned) cleaned = re.sub(r"\s*```$", "", cleaned) match = re.search(r"\{.*\}", cleaned, re.DOTALL) if match: cleaned = match.group(0) return json.loads(cleaned)

• 第一层：若响应以开头，用正则剥掉 Markdown 代码围栏（兼容 `json与``` ` 两种写法）；
• 第二层：用re.search(r"\{.*\}", cleaned, re.DOTALL)提取第一个{...}JSON 块，容忍模型输出的前后缀杂质；
• 最后交给json.loads反序列化为 Python dict，供后续渲染使用。

这套"提示词约束 + 正则兜底 + json.loads"的组合，是当前 LangChain 生态处理 LLM JSON 输出的常见稳健做法。

5.4 Markdown 渲染与容错

format_notes() 负责将 dict 渲染为 Markdown，包含多处容错：

• 各字段缺失时提供默认值（标题缺省为Meeting Notes、日期缺省为当天date.today().isoformat()、时长缺省为N/A）；
• action_items逐条渲染为- [ ] **任务** — Owner: xxx | Due: xxx的任务清单格式；
• blockers与next_meeting仅在该字段有值（且next_meeting != "TBD"）时才渲染对应章节，避免输出空标题。

六、内置示例与端到端验证

为便于零成本体验，SAMPLE_TRANSCRIPT 内置了一段 5 人参与的 Q4 产品路线图会议模拟，覆盖了典型会议元素：参会人介绍、feature freeze 日期决策（11 月 15 日）、支付集成进度汇报（Lisa 60%）、阻塞项（PaymentCo API 文档未回复）、行动项分工（John 当天升级、Lisa 11 月 10 日完成、Mike 11 月 11 日开始测试）、以及下次会议时间（11 月 10 日）。

运行python agent.py即可完整验证整个流水线：示例转录 → LLM 抽取 JSON → 解析 → Markdown 渲染 → 写入meeting_notes.md。这段示例文本的字段设计（决策、行动项、阻塞项、下次会议齐备）恰好与 NOTES_PROMPT 的 Schema 一一对应，是理解"转录文本如何映射到结构化字段"的最佳教材。

七、小结与适用场景

Meeting Notes Agent 是一个典型的单模型、提示词驱动的轻量 Agent：

• 架构极简：LangChain 消息抽象 + GPT-4o-mini + 本地 JSON/Markdown 处理，无外部编排依赖，150 行代码即可端到端跑通；
• 开箱即用：支持内置示例、转录文件、内联文本三种输入，默认输出meeting_notes.md且自动防覆盖；
• 可扩展方向（从源码结构推断）：可将输出改为其他格式（如 JSON 对接工单系统）、将转录输入换成实时语音转写（STT）结果、或把抽取出的 action_items 自动同步到项目管理工具。

它适合的典型场景包括：每周例会纪要以自动化速记、访谈与客户会议的关键结论沉淀、以及任何"口语转录 → 结构化行动清单"的流水线前置步骤。作为 500-AI-Agents-Projects 中 Productivity 分类的代表作，它为开发者提供了一个可直接复用的会议纪要 Agent 基线实现。

• 示例工程
• 人工智能