第六章框架开发实践 · 学习笔记（AutoGen / AgentScope / CAMEL / LangGraph）

学习材料 ：《Hello-Agents》第六章框架开发实践（docs/chapter6/第六章框架开发实践.md）

配套代码 ：code/chapter6/ 四个目录（AutoGenDemo/ · AgentScopeDemo/ · CAMEL/ · Langgraph/）

实验环境 ：腾讯云 Lighthouse（2C2G / 无 GPU ）· Ubuntu 26.04 · Python 3.14 · venv

模型：主用 kimi-k2.6 （Moonshot，temperature 只接受 1，组织 RPM=3）；另按要求以云端自部署模型 复测（llama.cpp + Qwen3-1.7B-Q4_K_M ，http://localhost:8080/v1）

实测规模 ：LangGraph / AutoGen / AgentScope 三个框架均真跑通 （LangGraph 与 AutoGen 为完整案例，AgentScope 为最小双智能体回合）；CAMEL 仅做 --dry-run 依赖解析验证（会降级 pydantic，为保已验证环境未实装）

关键词：多智能体协作 · AutoGen · RoundRobinGroupChat · AgentScope · 消息驱动 · CAMEL · 角色扮演 · Inception Prompting · LangGraph · 状态图 · 循环 · 涌现式协作 vs 显式控制
导读

第四章写的是一个智能体，第五章用平台把它"搭"出来，这一章面对的是一群 ------于是核心问题变成两句：

"谁来定规则？" 让协作从角色与目标里"涌现"出来（AutoGen / CAMEL），还是把每一步跳转都显式画出来（LangGraph）？"怎么扛住生产？" AgentScope 补上第三个维度：并发、容错、分布式。

本章 LangGraph、AutoGen、AgentScope 三个框架都在云端真跑通（附原始输出），多框架装进同一环境的依赖冲突也如实记录。

想判断该用哪个 → 看 §2.0 总表 与 §2.6 两条设计轴

想看实测与依赖冲突 → 看 §5 实验记录

自己在复习 → 用 §8 的自测清单 自问自答

本系列其他文章

上一章：第五章基于低代码平台的智能体搭建 · 学习笔记（Coze / Dify / FastGPT / n8n）
本章问题篇：第六章可能出现的问题：依赖冲突与成本乘法
全系列目录：hello-agent入门学习

一、知识地图

复制代码

第六章 框架开发实践
├── 6.1 从手动实现到框架开发 ───────────── 从"写脚本"到"用规范"
│   ├── 6.1.1 为何需要框架 ─────────────── 复用 / 解耦 / 状态 / 可观测
│   └── 6.1.2 四框架对比（表6.1）────────── AutoGen · AgentScope · CAMEL · LangGraph
├── 6.2 AutoGen ────────────────────────── 以对话驱动协作
│   ├── 6.2.1 核心机制（0.7.x 组合式架构）
│   ├── 6.2.2/6.2.3 软件开发团队案例
│   └── 6.2.4 优势与局限
├── 6.3 AgentScope ─────────────────────── 工程化与易用性
│   ├── 6.3.1 设计（消息驱动 / MsgHub）
│   ├── 6.3.2 三国狼人杀（结构化输出）
│   └── 6.3.3 优势与局限
├── 6.4 CAMEL ──────────────────────────── 角色扮演 + 初始提示
│   ├── 6.4.1 自主协作
│   ├── 6.4.2 AI科普电子书案例
│   └── 6.4.3 优势与局限
├── 6.5 LangGraph ──────────────────────── 状态图 / 显式控制
│   ├── 6.5.1 结构梳理（StateGraph / 节点 / 边 / 条件边）
│   ├── 6.5.2 三步问答助手
│   └── 6.5.3 优势与局限
└── 6.6 本章小结 ───────────────────────── 涌现式协作 vs 显式控制 + 工程化维度

一句话主线 ：第四章我们写的是一个智能体；第五章我们用平台把它"搭"出来；第六章面对的是一群智能体------于是核心问题变成了：

"谁来定规则？" ------ 是让协作从角色与目标里"涌现"出来 （AutoGen / CAMEL：你只写角色，行为自己长出来），还是把每一步跳转都显式画出来 （LangGraph：你写状态机，行为完全可控）？

"怎么扛住生产？" ------ AgentScope 给出了第三个维度：并发、容错、分布式。

读完这一章应该能做到一件事：拿到一个多角色需求，先判断它落在"涌现"还是"显式控制"这一侧，再挑框架------而不是默认选名气最大的那个。

二、核心概念

2.0 先立骨架：四框架总表（本章最该背下来的一张表）

框架	抽象	协作怎么发生	最强的一手	主要代价
AutoGen	群聊（GroupChat）	多个"可对话"智能体按规则轮流/自动发言	角色分工 + 对话规则极简；生态成熟	对话容易跑偏/循环；不确定性高
AgentScope	消息驱动的多智能体平台	通过 `MsgHub` 广播消息，智能体各自响应	工程化：并发、分布式、结构化输出	上手成本高于 AutoGen；生态较新
CAMEL	角色扮演对（Role-Playing）	两个角色在"初始提示"引导下自主多轮对话	代码量最少；激发深度协作	双人范式为主；终止/冲突处理弱
LangGraph	状态图（StateGraph）	节点 = 一步操作，边 = 跳转条件，天然支持循环	显式控制 + 可靠性，Reflection 类循环极自然	要自己画图；灵活度靠你来写

🔑 本章最关键的一句判断："涌现式协作"（AutoGen / CAMEL）更贴近人类交互，但难以预测和调试；"显式控制"（LangGraph）牺牲惊喜，换来可靠、可控、可观测。 这不是优劣，是取舍。

2.1 为什么需要框架（四个价值）

复用与效率：Agent Loop、状态管理、工具调用被封装，不用每次重写。
解耦与可扩展：强制分层------模型层 / 工具层 / 记忆层各自独立，"换模型不动业务"。
标准化状态管理 ：第四章那个 20 行的 Memory 只是开始；长时运行要做上下文窗口、持久化、多轮状态跟踪。
可观测性 ：通过事件回调 （on_llm_start / on_tool_end / on_agent_finish）自动埋点，比手写 print 系统得多。

💡 可迁移经验 ：第 4 条是框架最被低估 的价值。第四章调试 ReAct 时我们是靠打印日志"猜"哪一步出问题；有回调机制时，每一步的入参出参都会被结构化记录下来------这是从"能跑"到"能维护"的分水岭。

2.2 AutoGen：把协作抽象成一场"群聊"

核心机制 ：把多智能体系统抽象为由多个"可对话"智能体组成的群聊。任务解决 = 消息在群里自动流转、迭代，直到达成目标。
版本注意 ：本章以 0.7.4 为例，这是一次重要架构重构 ------从"类继承设计"转向组合式架构 （AssistantAgent + OpenAIChatCompletionClient + Team 组合）。
案例：「软件开发团队」用 RoundRobinGroupChat（轮询群聊）让 ProductManager → Engineer → CodeReviewer → UserProxy 按固定顺序发言，用 TextMentionTermination("TERMINATE") 收尾。

⚠️ 必须写进笔记的结论 ：AutoGen 的"涌现"来自角色 + 顺序 这两件事。它不承诺行为可预测 ------max_turns 是唯一的安全阀。实测中我把它从 4 角色/20 轮砍到 2 角色/4 轮，因为轮数直接乘上 LLM 调用次数。

2.3 AgentScope：把"能跑"变成"能稳定服务"

定位：专为多智能体应用设计的开发平台，强调易用性 + 工程化。
两个技术标志 ：
- 消息驱动架构 （MsgHub 消息中心）------不同于函数调用，智能体之间通过广播消息解耦；
- 结构化输出 ------用 DiscussionModelCN / WitchActionModelCN 之类模型约束智能体输出到确定字段，而不是解析自由文本。
案例：「三国狼人杀」------多角色、多轮、需要严格约束行为。

🔑 点睛：结构化输出正是第四章"正则解析自由文本"的正式解法。 第四章我们靠正则从 LLM 输出里抠 Action，脆弱且易崩；AgentScope 直接要求模型按 schema 产出------这是同一个问题的工程化答案。

2.4 CAMEL：最少的代码，最深的协作

核心方法 ：角色扮演（Role-Playing）+ 初始提示（Inception Prompting）。你只定义两个角色（如"AI心理学家" + "AI作家"）和共同目标，它们就能自主多轮对话、互相启发。
案例：AI科普电子书------作家提结构要求，心理学家提供专业内容。
终止：检测到 <CAMEL_TASK_DONE> 标志时强制结束。

⚠️ 它的软肋 ：如果两个角色一个认为该结束、一个认为不该结束 ，就出现"意见分歧无法收敛"。CAMEL 没有内建的冲突仲裁机制------这正好是本章习题 4 要你补的那块。

2.5 LangGraph：把流程画成一张图（本章最"可控"的一个）

核心抽象 ：StateGraph + 节点（Node） + 边（Edge） + 条件边（Conditional Edge）。
状态：用一个 TypedDict 定义全局状态（如 SearchState），节点函数接收 state、返回对 state 的增量更新。
天然支持循环 ：普通边 + 条件边可以构成环，"生成 → 评估 → 再生成"这类 Reflection 循环就是一条回边。

🔑 点睛：第四章的 Reflection，在 LangGraph 里就是"一条回边"。 同一个控制流------第四章用手写 for 循环 + Memory 实现，LangGraph 用图结构表达。框架没有发明新范式，它只是把范式变成了声明式配置。

2.6 两条设计轴（本章的"世界观"）

复制代码

轴一（协作方式）：  涌现式协作 ←──────────────→ 显式控制
                 (AutoGen / CAMEL)          (LangGraph)

轴二（工程能力）：  实验原型 ←────────────────→ 生产服务
                 (脚本 / AutoGen 默认)       (AgentScope)

两个轴是独立的：你可以"涌现式协作 + 生产级工程"（AutoGen + AgentScope），也可以"显式控制 + 生产级工程"（LangGraph + 自己补并发）。

三、把第六章"接回"前五章

第六章的概念	在第几章"活"过来
`AssistantAgent` + 模型客户端	第四章（`HelloAgentsLLM` 的框架化封装）
`TextMentionTermination("TERMINATE")`	第四章（ReAct 的 `Finish[...]` 终止信号）
AgentScope 的结构化输出	第四章（正则解析的正式解法）
LangGraph 的循环边	第四章（Reflection 的执行-反思-优化循环）
角色分工（PM / Engineer / Reviewer）	第一章（System Prompt 里的角色定义）+ 第五章（Dify 问题分类器）
多智能体消息编排	第五章（平台里的多智能体模式）
框架的工程化（并发/容错）	后续章节（记忆、上下文工程、评估）

四、代码精读（`code/chapter6/` 四个目录）

4.1 `Langgraph/Dialogue_System.py`（259 行）------最值得逐行读的一个

状态定义 ：SearchState(TypedDict)，用 Annotated[list, add_messages] 让消息自动追加而不是覆盖。
三个节点 ：understand_query_node（生成搜索词）→ tavily_search_node（真实搜索）→ generate_answer_node（作答）。
图的构建只有 6 行：

python 复制代码

workflow.add_edge(START, "understand")
workflow.add_edge("understand", "search")
workflow.add_edge("search", "answer")
workflow.add_edge("answer", END)

两个硬依赖 ：TAVILY_API_KEY（少了直接 return）与交互式 input()（无头环境无法直接跑）。
⚠️ search_failed 分支值得注意 ：搜索失败时它回退为"基于 LLM 知识回答" ，并要求"说明这是基于已有知识的回答"------这正是第四章 ReAct 缺的那道"来源纪律"提醒。

4.2 `AutoGenDemo/autogen_software_team.py`（194 行）------角色分工的模板

四个角色各自一个 system_message，并且每个角色的 system message 结尾都埋了一个"交接口令"：产品经理说"请工程师开始实现"、工程师说"请代码审查员检查"、审查员说"请用户代理测试"。
这套"口令接力"就是协作协议本身 ------比显式状态机便宜，但依赖模型每次都记得说口令。

4.3 `AgentScopeDemo/` ------结构化输出的示范

game_roles.py（角色）、structured_output_cn.py（约束模型）、main_cn.py（主流程）、prompt_cn.py（提示词）、utils_cn.py。
关键设计 ：把角色行为约束成结构化模型，而不是自由文本。

4.4 `CAMEL/DigitalBookWriting.py` ------最短的协作代码

定义两个角色 + 一个任务 → init_chat() 生成初始对话 → 循环对话到 <CAMEL_TASK_DONE>。
代码量最少，但可控性也最低。

五、实验记录（Lighthouse / Python 3.14 / 2C2G / kimi-k2.6）

口径声明 ：本章所有结论来自服务器真跑。Python 3.14 是很新的版本 ，框架兼容性是本轮最大的不确定性，故每个框架都先做"可安装 + 可导入 + 可运行"三级验证，装不上/跑不动的如实标注，不冒充跑通。

5.0 环境自检：三个框架能否共存于一个 venv

包	版本	安装	导入
`langgraph`	1.2.11	✅	✅
`langchain-core`	1.6.3	✅	✅
`langchain-openai`	1.6.2	✅	✅
`autogen-agentchat` / `autogen-core` / `autogen-ext`	0.7.5	✅	✅
`agentscope`	2.0.8	✅	✅
`camel-ai`	0.2.90（dry-run）	⏭️ 未实装：`pip install --dry-run` 验证可解析，但会降级 pydantic 2.13→2.12 、`tiktoken`、`websockets` 等多个包------为保住已验证环境未实际改动	---

⚠️ 实测暴露一个必须记的坑 ：装 agentscope 时 pip 报依赖冲突 ------

autogen-core 0.7.5 requires protobuf~=5.29.3, but you have protobuf 7.36.2。

但三个框架的导入层都通过 （protobuf 7.36.2 实测可导入）。所以这是潜在风险而非立即故障 ：版本约束被违反，运行时某些 gRPC/OTLP 路径可能炸。
💡 可迁移经验 ：多框架共存要按 venv 隔离。 一个 venv 装四个框架，迟早撞依赖。本轮里 autogen 与 agentscope 已经撞上了------这本身就是"为什么要用虚拟环境"的现场证据。

5.1 LangGraph：✓ 通过（三段式状态图跑通）

节点执行序列实测：understand → search → answer，退出码 0。

节点	实测行为
`understand`	生成搜索词；实测把一堆候选拼成了一条长查询（`华为最新手机型号 2024，华为Pura 70，华为Mate 70，Huawei latest flagship phone selling points`）------字段抽取逻辑把整段都吞了
`search`	复用 Bing 搜索（替代 Tavily），返回真实条目
`answer`	拒绝作答："目前无法确认 ......搜索结果均为华为官方通用页面或企业介绍，未包含 Pura 70 / Mate 70 的详细规格与卖点......信息不足"

⭐ 这是本章最值得记的一组对比 ：

同一个"搜索 → 回答"链路，第四章 ReAct 在搜索为空时"编"出了 Kirin 9100；第六章 LangGraph 在搜索结果不相关时，明确回答"信息不足"。

差别不在模型（都是 kimi），而在提示词与节点设计 ------LangGraph 的 answer 节点要求"引用来源、信息不足时明确说明 "，而 ReAct 的提示词对"来源可靠性"零约束。

结论：幻觉的防线可以建在提示词里，不必指望模型自觉。

5.2 AutoGen：✓ 通过（2 角色群聊跑通）

实测把案例从 4 角色 / max_turns=20 压缩到 2 角色 / max_turns=4（RPM=3 的现实约束），任务改为"实现判断闰年的函数"：

角色	实测输出
`ProductManager`	完整需求文档：核心规则（4/100/400）、输入约束、异常策略 Fail-fast 、边界表（专门指出 `bool` 是 `int` 子类，必须显式拒绝）
`Engineer`	`is_leap_year(year: int) -> bool`：含类型注解、docstring、`isinstance(year, bool)` 显式拒绝、`year < 1` 抛 `ValueError`、`if __name__ == "__main__"` 测试块
终止	Engineer 输出单独一行 `TERMINATE` → 群聊结束，退出码 0

⭐ 涌现式的价值在这组实测里很直观 ："显式拒绝 bool"这条边界，我并没有写在任务描述里 ------它是产品经理自己分析出来的，然后被工程师落进了代码。角色分工确实能"长"出你没要求的严谨。

5.3 AgentScope：✓ 通过（最小双智能体回合跑通）

agentscope 2.0.8 安装成功、可导入，并实跑了一个最小双智能体回合 （Agent.reply() + MoonshotChatModel，两角色依次发言，退出码 0）：

角色	实测输出（节选）
`Researcher`	"智能体的记忆不应仅被视为信息的被动存储，而应被设计为主动塑造其未来感知、推理与行动的动态认知架构......"
`Writer`	"智能体的记忆不是简单的'存档柜'，而是会主动帮它预判未来、决定下一步怎么想的'导航仪'。"

要点：消息通过 Msg 对象传递（content 必须是内容块列表 ，实测传裸字符串会被 pydantic 拒绝），回复回来的是结构化 TextBlock------这正是"结构化输出"理念的落地，与第四章正则抠自由文本形成对照。

"三国狼人杀"案例仍未跑 ：它是多轮多角色游戏（通信回合数远高于 2），在 RPM=3 的额度下预计要跑十几分钟以上。如实标注，不冒充跑通。

5.4 复测：改用云端自部署模型（Qwen3-1.7B）

把 .env 切到服务器自部署的 llama.cpp / Qwen3-1.7B（http://localhost:8080/v1，别名 qwen3-1.7b-q4，--reasoning off），原代码不改一行重跑 LangGraph 三段图：

项	kimi-k2.6	Qwen3-1.7B（自部署）
图执行	`understand → search → answer` ✅	同样 3 节点跑通 ✅
搜索词	长串拼接（字段抽取吞整段）	`huawei latest phone model 2025 selling points`（更干净）
回答	拒绝作答："信息不足......未包含详情"	给出 `Mate 60 系列`，但标注"基于常规市场信息推断，搜索结果未提供具体型号"
计费 / 限流	按 token 计费 / RPM=3	零费用 / 无限流

两个观察：

框架层与模型层是解耦的 ------同一份 LangGraph 代码，换模型只需改 .env 三行，图结构与节点逻辑完全不动。这正是第六章"框架解耦"的直接证据。
小模型更"敢答" ：kimi 版本严守"信息不足就说不足"，1.7B 版本则在标注"这是推断"之后仍给出了具体机型。同一条"来源纪律"提示词，在能力更弱的模型上约束力更弱 ------提醒我们：纪律条款对模型的约束强度，与模型能力正相关。

5.5 实验总表

#	实验	期望	实测	结论
0	依赖共存	三框架装进一个 venv	装上，但 autogen↔agentscope protobuf 冲突	⚠️ 需 venv 隔离
1	LangGraph 三段图	3 节点顺序执行	`understand→search→answer`，退出码 0	✅
2	LangGraph 的"诚实性"	依据不足时说"不足"	明确回"信息不足"	✅ 对比第四章的编造
3	AutoGen 群聊	角色接力完成	需求文档 + 闰年代码 + TERMINATE	✅
4	AgentScope 最小回合	两智能体消息传递	Researcher→Writer，退出码 0	✅
5	AgentScope 狼人杀案例	多轮多角色游戏	未跑（RPM=3 下预计十几分钟）	⏭️ 未跑

六、踩坑与改进思考

6.1 缺陷清单（框架使用视角）

#	缺陷	实测证据	影响
1	多框架共 venv 撞依赖	`autogen-core requires protobuf~=5.29.3, but you have protobuf 7.36.2`	今天能导入，明天某个 gRPC 路径可能炸
2	Python 3.14 兼容性未验证	框架轮子按 3.10/3.11/3.12 发布	靠镜像源碰运气；老项目建议锁 3.11/3.12
3	仓库 LangGraph 示例需交互式 `input()`	259 行里 `user_input = input(...)`	无头/CI 环境直接跑不了，必须改造为参数化
4	仓库示例硬依赖 Tavily	`if not os.getenv("TAVILY_API_KEY"): return`	没 key 时静默退出，看不到任何输出
5	轮数直乘调用次数	AutoGen 案例 `max_turns=20` × 4 角色	RPM=3 下等于十几分钟起步；成本与延迟被系统性低估
6	字段抽取逻辑把整段吞掉	`understand` 节点产出的搜索词是长串拼接	下游搜索质量下降（实测确实搜回了泛泛的结果）
7	"口令接力"式协作脆弱	AutoGen 靠 system message 里的"请工程师开始实现"	模型忘说口令 → 协作卡住或跑偏

6.2 修复方向

缺陷	修复
1	每个框架一个 venv （或容器）；用 `uv`/`pip-tools` 锁依赖
2	显式锁定 Python 3.11/3.12；CI 里跑一遍"导入冒烟测试"
3	把示例改成"命令行参数 + 单次执行"，把交互留给上层 UI
4	缺 key 时显式报错退出（非零退出码），并支持注入替代搜索（本轮用 Bing 兜住）
5	先算"总调用数 = 轮数 × 角色数"，据此设 `max_turns` 与预算护栏
6	字段抽取用结构化输出（AgentScope 的思路），而不是 `split("搜索词：")[1]`
7	口令改为终止/交接的机器可判定信号（如 `TERMINATE` 那样），而不是自然语言祈使句

6.3 我在方法上踩的坑

差点把"示例代码跑不起来"归咎于框架 。真实原因是示例本身假设了交互式终端 + Tavily key ------这是示例的工程假设，不是框架的缺陷。判据要分清："框架不行"和"示例没为无头环境设计"。
把 4 角色 20 轮直接跑，等于给自己挖坑 。RPM=3 的额度下，我意识到"总调用数 = 轮数 × 角色数"这个乘法后，主动砍成 2×4。先算成本再启动，比跑一半被限流强。
只装不跑 ≠ 验证 。AgentScope 最初我只装了没跑，交付前补了一个最小双智能体回合才敢写"跑通"。拿安装日志冒充运行结果，是最容易自欺的一步 ------装上了只是"能装"，不是"能用"。

6.4 自我拷问（grill）

"AgentScope 跑到什么程度才算'跑通'？" ------最小双智能体回合算"能用"，但不等于"案例跑通" 。写"通过"的前提是有真实输出日志 （本轮有）；而"三国狼人杀"那种多轮案例仍属未跑 。两者必须分开标注，不能合并成一句"AgentScope 已验证"。
"AutoGen 相比第四章手写，强在哪？" ------强在角色分工能自发产生严谨性 （实测：bool 边界是模型自己提的），以及省掉了编排代码 。弱在可预测性------你没写它会检查 bool。
"LangGraph 一定更适合生产吗？" ------不一定。它更可控、更易观测，但所有分支都要你自己想全 。前提：你已经知道流程长什么样。 探索性任务用它会很痛苦。
"框架是不是越多越好？" ------本轮实测给了反例：同一个 venv 里 autogen 和 agentscope 已经 protobuf 冲突 。框架数量与维护成本是正相关的。

七、习题思路速记

习题 1 · 两框架深对比 + 涌现 vs 显式

以 AutoGen vs LangGraph 为例：协作模式（AutoGen = 群聊轮询/自动发言；LangGraph = 图上的边跳转）、控制方式（AutoGen = 靠角色与规则"涌现"；LangGraph = 每步跳转显式声明）、适用场景（AutoGen = 开放的探索/写作/评审；LangGraph = 有明确阶段与回退的流程）。
"涌现式协作"= 只定义角色与目标，协作行为从对话中自发产生 （像真实团队）；"显式控制"= 每个状态与跳转都被写死（像流水线）。前者灵活难调试，后者刻板可靠。

习题 2 · AutoGen 团队扩展

动态回退 ：把 RoundRobinGroupChat 换成带选择器的协作 （如 SelectorGroupChat），由选择器根据上下文决定下一个发言者；或自定义"回退规则"（工程师输出里出现"需求不清"就把发言权交回 PM）。
新增测试工程师 ：system_message 写清"在代码审查后执行自动化测试、输出用例与结果、失败则指名交回 Engineer"，并埋交接口令。
对话质量监控 ：加一个监督角色/回调 ，检测"重复发言、话题漂移、超过 N 轮无进展"；命中则插入提示或强制终止。回调（on_agent_finish）比再加一个 agent 更省成本。

习题 3 · AgentScope 深入

MsgHub 的优势：消息驱动 = 发布/订阅式解耦 。智能体不需要知道对方是谁，只对消息类型做响应。特别适合"多人实时交互"场景（游戏、会议、仿真），因为增删参与者不改其他角色代码。
新增"猎人"角色：定义一个结构化输出模型（如 HunterActionModel，字段 target: int、action: Literal["shoot","skip"]），加校验规则（目标必须在存活玩家中、每局仅一次）。
分布式挑战：消息顺序性 （同一局内多台机器产生的事件要定序）、一致性 （投票/状态同步）。解法：中心化排序服务 / 逻辑时钟（Lamport）、幂等消息、关键状态单点写入。

习题 4 · CAMEL 冲突解决

分歧场景：两端对 <CAMEL_TASK_DONE> 的判断不一致。
兼容机制 ：① 第三个"仲裁者"角色 （或程序侧规则）在双方意见冲突时介入；② 投票 + 轮次阈值 （连续 N 轮无新增信息则强制结束）；③ 程序侧兜底 ------把终止权从"对话内容"收回到"控制器"（对话决定想不想停，控制器决定能不能停）。

习题 5 · LangGraph 深化

画图：START → understand → search → answer → END，线性四条边（与本轮实测一致）。
加"反思"节点 ：answer → reflect →（条件边）：质量达标 → END；不达标 → search（重新搜索）或 answer（重写）。条件边的判据建议用显式评价模型（如"要点覆盖数 < 阈值"），而不是让模型自己说"我需要再搜"。
更复杂应用 ：「代码生成-测试-修复」循环------generate → test →（失败）fix → test ...（通过）→ END。关键节点：生成、执行测试、诊断失败、修复；回边最多重试 N 次。

习题 6 · 三产品选型

应用A（智能客服，1000+ QPS，2 秒内响应，7×24，可水平扩展） → 不借助框架从零 / AgentScope（工程化） 。理由：吞吐与延迟是主体 ，LLM 只占其中一步；AutoGen 的对话式协作在这种场景是负担，LangGraph 有额外开销。需要的是无状态服务 + 缓存 + 流式。
应用B（科研论文辅助，研究员 + 写作双智能体深度协作） → CAMEL （双角色深度协作的原生场景）或 AutoGen（需要更多角色时）。
应用C（金融风控审批，严格流程 + 分支 + 可追溯可审计） → LangGraph 。理由：流程显式、分支清晰、要求可审计------正是"显式控制"的主场；图结构天然可追踪每一步跳转。

八、本章小结

本章回顾

节	一句话
6.1	框架的价值 = 复用 / 解耦 / 标准化状态 / 可观测
6.2	AutoGen 把协作抽象成群聊，靠角色+顺序让行为"涌现"
6.3	AgentScope 补上工程化（消息驱动、结构化输出、分布式）
6.4	CAMEL 用角色扮演 + 初始提示，以最少代码激发深度协作
6.5	LangGraph 把流程画成状态图，用回边天然表达循环
6.6	两条设计轴：涌现 ↔ 显式控制；原型 ↔ 生产

核心"公式"

复制代码

多智能体系统的可控性 ∝ 你显式声明的约束数量
    ← 声明得越少（只给角色），越"涌现"，越像人，越难调试
    ← 声明得越多（每步跳转），越可控，越像流水线，越缺惊喜

生产可用性 ∝ 工程化程度（并发 / 容错 / 状态持久化 / 可观测）

三句话记住本章

框架没发明新范式，它把第四章的控制流"声明化"了：Reflection 变成一条回边，Plan-and-Solve 变成一张图。
"涌现"与"可控"是一对取舍，不是优劣 ：AutoGen 能长出你没要求的严谨（实测：bool 边界），代价是你不写它就不知道它会干什么。
多智能体的成本是乘法 ：总调用数 = 轮数 × 角色数------实测中 4 角色 × 20 轮在 RPM=3 下要十几分钟，先算账再启动。

与前后章的呼应

第六章	在哪一章"活"过来
框架的模型层封装	第四章（`HelloAgentsLLM`）
终止信号 `TERMINATE`	第四章（`Finish[...]`）
结构化输出	第四章（正则解析的正式解法）
LangGraph 的循环边	第四章（Reflection 循环）
多智能体编排	第五章（平台的多智能体模式）
状态管理与记忆	后续章节（记忆、上下文工程、评估）

自测清单（能答上来说明真懂了）

为什么说 LangGraph 没有发明新范式，只是把 Reflection"声明化"了？
AutoGen 的"涌现式协作"具体"涌现"在哪两件事上？（角色 + 顺序/规则）
AgentScope 的结构化输出，解决了第四章的哪个具体痛点？
MsgHub 的消息驱动相比函数调用，优势是什么？什么场景最受益？
为什么"多框架共用一个 venv"必然出问题？本轮实测撞的是哪个包？
为什么 LangGraph 在本轮"拒绝作答"，而 ReAct 在第四章"编造答案"？（提示词里的来源纪律）
AutoGen 的"口令接力"为什么脆弱？怎么改成可靠信号？
应用 C（金融风控）为什么选 LangGraph 而不是 AutoGen？

下一步

本章是"用别人的框架"。下一章会把这一路的经验收回来------从零构造一个属于我们自己的智能体框架 。回头看，我们知道那个框架必须内置：Agent Loop（第四章）、工具注册（第四章）、记忆（第四章 Reflection / 第八章）、可观测回调（第六章）、以及一套显式的控制流（LangGraph 那一侧）。

💡 最后留一个我印象最深的对比 ：同一个"搜索 → 回答"链路、同一个模型 （kimi-k2.6），

第四章 ReAct 在搜索失败时，编出了一个芯片型号；第六章 LangGraph 在结果不相关时，回答"信息不足"。

差别不在框架的"智能"，而在提示词里有没有写下"不许编"这条纪律。

第六章 框架开发实践 · 学习笔记（AutoGen / AgentScope / CAMEL / LangGraph）

一、知识地图

二、核心概念

2.0 先立骨架：四框架总表（本章最该背下来的一张表）

2.1 为什么需要框架（四个价值）

2.2 AutoGen：把协作抽象成一场"群聊"

2.3 AgentScope：把"能跑"变成"能稳定服务"

2.4 CAMEL：最少的代码，最深的协作

2.5 LangGraph：把流程画成一张图（本章最"可控"的一个）

2.6 两条设计轴（本章的"世界观"）

三、把第六章"接回"前五章

四、代码精读（code/chapter6/ 四个目录）

4.1 Langgraph/Dialogue_System.py（259 行）------最值得逐行读的一个

4.2 AutoGenDemo/autogen_software_team.py（194 行）------角色分工的模板

4.3 AgentScopeDemo/ ------结构化输出的示范

4.4 CAMEL/DigitalBookWriting.py ------最短的协作代码

五、实验记录（Lighthouse / Python 3.14 / 2C2G / kimi-k2.6）

5.0 环境自检：三个框架能否共存于一个 venv

5.1 LangGraph：✓ 通过（三段式状态图跑通）

5.2 AutoGen：✓ 通过（2 角色群聊跑通）

5.3 AgentScope：✓ 通过（最小双智能体回合跑通）

5.4 复测：改用云端自部署模型（Qwen3-1.7B）

5.5 实验总表

六、踩坑与改进思考

6.1 缺陷清单（框架使用视角）

6.2 修复方向

6.3 我在方法上踩的坑

6.4 自我拷问（grill）

七、习题思路速记

八、本章小结

本章回顾

核心"公式"

三句话记住本章

与前后章的呼应

自测清单（能答上来说明真懂了）

下一步

第六章框架开发实践 · 学习笔记（AutoGen / AgentScope / CAMEL / LangGraph）

四、代码精读（`code/chapter6/` 四个目录）

4.1 `Langgraph/Dialogue_System.py`（259 行）------最值得逐行读的一个

4.2 `AutoGenDemo/autogen_software_team.py`（194 行）------角色分工的模板

4.3 `AgentScopeDemo/` ------结构化输出的示范

4.4 `CAMEL/DigitalBookWriting.py` ------最短的协作代码