一个 agent 什么都干就什么都平庸 — 拆分、编排,以及 bug 长在接缝上
这一章讲三件事: 为什么让一个 agent 什么都干,结果是什么都干不好; 拆成几个之后,它们之间靠什么传话、谁决定下一步走哪儿; 以及一条几乎所有人都会踩的坑——你测了每个 agent 都对,系统还是错的。
它在全书链条里的位置: 第 12 到 15 章建起了一个 agent。 这一章讲多个 agent 怎么协作,是全书第二层的收尾。 从第 17 章起进入第三层:怎么知道这一切一直在正常工作。
1. 顶层全景:一张靴子照片,加两句追问
这一章的主走查是书里最好的一个例子,一次交互就把四种能力全逼出来了:
顾客发来一张自己徒步靴的照片,写道:「你们有类似但防水的吗?」 几秒之后又补一句:「要是不合脚,你们的退货政策是什么?」
① 照片先过一个图像描述程序 → 得到一个短标签:`trail hiking boots`
▼
② 和用户的文字拼在一起 → `trail hiking boots waterproof`
▼
③ 用一个**小模型**判断这句话要什么 → 返回 `{search_needed: true, qa_needed: true}`
▼
④ 按这个判断选路:走「两样都要」那一支
▼
⑤ 搜索那一支干活 → 取到 3 件商品
▼
⑥ 兜一道:搜索结果的文字里出现了 return / warranty
→ **把「要问答」强制置真**(哪怕第 ③ 步没判出来)
▼
⑦ 政策那一支干活 → 取到退货条款
▼
⑧ 换用**完整模型**,把两份结果写成一条连贯的回答
▼
⑨ 最后做一次破坏测试:把搜索那一支换成一个直接报错的假函数,
断言回答里有「抱歉」,**但不许出现「error」这个词**
图说:③④⑥ 是这一章新增的机制(判意图、选路、兜底回补),
⑤⑦ 是第 13 章那个循环的重演,⑧ 是这一章的落点。
**3 件商品是为演示设的;`trail hiking boots`、那几个回补词、
以及第 ⑨ 步的断言都是书里的原样。**
2. 先看现象:一个 agent 全扛,会怎么坏
这一节讲这一章存在的理由,而它的三个症状都很具体。
上一章留下的问题
第 14、15 章造出来的工具很能干,但书指出它们有一个共同的毛病:
它们是孤立的。每一个都把自己那件事干得很好, 但谁也不知道别人的存在,谁也不能决定什么时候把活交给另一个, 也不能把几份结果合成一个回答。1
一个模型扛所有责任,书给的三个症状
一个模型同时兼顾所有这些职责,就会样样都平庸。2
| 症状 | 具体发生了什么 |
|---|---|
| 上下文被无关信息填满 | 它一次能读进去的量是有限的,而你把商品目录、退货条款、图片描述全塞了进去 |
| 回复变得前后不一致 | 同一段系统提示词(每次对话都自动加在最前面、规定它扮演什么角色守什么规矩的那段固定指令)要同时管「像销售一样热情」和「像客服一样严谨」,它会在两者之间摇摆 |
| 加新能力得重写整个系统 | 想再加一个查库存的本事,你得回去改那一大坨提示词,而改完前面的能力可能就变了 |
一句话里藏着三种不同的智能
书给了第二个例子,拆得更清楚:
「我要一件 200 美元以下、适合冬季露营的保暖夹克,还想知道你们户外装备的保修条款。」
这一句实际上需要三种完全不同的本事3:
① 找货: 在商品库里按「保暖 + 冬季露营 + 200 美元以下」筛
—— 这是一个检索问题
② 懂规则:「户外装备的保修条款」在政策文档里,而且常有例外条款
—— 这是一个理解与解释问题
③ 合成: 把上面两份结果写成一条**连贯、像人说的**回答
—— 这是一个写作问题
图说:**这三件事需要的东西不一样。** ① 要的是检索准,
② 要的是理解细致,③ 要的是文字连贯。
**让同一个提示词同时擅长这三样,就是「样样平庸」的由来。**
于是拆成三个,各管一摊:一个专管找货、一个专管业务规则和客服口径、 一个专管理解用户要什么并把回答编排起来。
3. 拆完之后,它们靠什么串起来:五个 概念
这一节是这一章的机制底座。五个概念一次给全,但它们其实只回答三个问题。
问题一:agent 之间怎么传话? → **共享状态**
问题二:一个「步骤」是什么? → **节点**
问题三:下一步走哪儿? → **边**,以及会看情况的**条件边**
——把上面这些装在一起的整体 → **图**
| 概念 | 是什么 | 拿主走查举例 |
|---|---|---|
| 共享状态 | 一份所有 agent 都能读、都能写的数据,像一块公用的白板 | 上面写着:用户原话、图片标签、要不要搜、要不要问答、搜到了什么、政策是什么 |
| 节点 | 一个 agent,或者一个处理步骤 | 「判意图」是一个节点,「搜商品」是一个节点 |
| 边 | 两个节点之间的连线,规定 做完这个做哪个 | 「搜商品」做完 → 「合成回答」 |
| 条件边 | 一条会看状态再决定往哪走的线 | 看白板上「要不要搜 / 要不要问答」这两格,决定走三条支线里的哪一条 |
| 图 | 把上面全部装起来的那整个流程 | 主走查那张图的全部 |
这五个词里,条件边是唯一真正新的东西——其余四个都只是给已有的概念起了名字。 它之所以要紧,是因为它把「下一步走哪儿」这个决定,从写死的代码里挪到了运行时的数据上。
书还列了这类编排工具比「简单的函数调用或基础路由」多出来的五件事4:
| 多出来的 | 它解决什么 |
|---|---|
| 状态管理 | 上面那块公用白板 |
| 条件路由 | 上面那条条件边 |
| 循环管理 | 支持多步推理和 agent 之间来回协作(不只是一条道走到黑) |
| 错误处理 | 优雅降级——一个坏了,别的继续 |
| 可观测性 | 能把整张流程图画出来看,方便调试 |
4. 判断用户要什么:不许用关键词
这一节讲主走查第 ③ 步,而它有一句书专门写下的告诫。
先看现象:关键词判意图必错
用户说「要是不合脚怎么办?」——这句话里既没有「退货」也没有「政策」。 一张关键词表判不出它其实是在问政策。
书的原话很直接:
不要用脆弱的关键词匹配,用模型的函数调用来稳健地解析用户意图。5
(这和第 13 章那条「护栏用词表一定会漏」是同一个道理: 你要判断的是意图,而意图有无穷多种说法。)
做法:定义一个专管判意图的函数,并且强制它必须调
定义一个函数(第 05 章那个函数调用):
analyze_intent(search_needed: bool,
qa_needed: bool,
reasoning: str) ← 顺带让它写出判断理由
调模型时把参数设成「必须调用这个函数」
用户说:「你们有类似但防水的吗?……要是不合脚,退货政策是什么?」
▼
模型返回:{ "search_needed": true,
"qa_needed": true,
"reasoning": "既要找替代商品,又问了退货条款" }
图说:**注意这里没有任何一处在解析自由文本。**
书在代码注释里写明了理由:**用函数调用而不是去解析一段 JSON,是为了避免出错**——
**模型写自由文本时可能多写一句解释、少一个括号,而函数调用的参数是有格式约束的。**[^6]
还有一条兜底:如果模型这次没有返回任何函数调用,就默认成「要搜索,不要问答」。 这条兜底的思路和第 15 章那条「优雅地失败」是一样的:宁可走一条保守的默认路径, 也不要因为没判出意图就整条流程崩掉。
一条书自己加的回补规则
走查第 ⑥ 步:搜商品那个节点干完活之后,还做了一件额外的事。 它用的是一条启发式规则(不追求每次都判对、只求「大致对而且成本极低」的经验规则)6:
搜索返回的文字里,只要出现下面任何一个词:
care(保养) / return(退货) / policy(政策) / warranty(保修) / sizing(尺码)
▼
就把白板上的「要不要问答」这一格**强制置为真**
—— **哪怕第 ③ 步的意图分析没判出来**
图说:**这是一道二次机会。** 意图分析在用户那句话上没看出政策需求,
但商品数据本身提到了退货条款,说明这个话题确实相关。
**注意这一道用的恰恰是关键词——书在这里没有自相矛盾:
关键词不能用来做主判断,但可以用来做「宁可多做一步」的补救。**
5. 多个 agent 反而更省钱
这一节讲一个反直觉的点,而它是书自己点破的。
直觉是:拆成三个 agent,就要调三次模型,当然贵三倍。
书说不是7:
| 这一步干什么 | 用哪种模型 | 为什么 |
|---|---|---|
| 判意图、抽参数 | 小模型 | 这是一个简单的路由决定,不需要文采也不需要深度理解 |
| 合成最终回答、解释保修的细微例外 | 完整模型 | 这里质量最要紧,写得不连贯或者把例外条款讲错,用户直接受损 |
书的原话:这是多 agent 架构的关键优势之一——每个 agent 都能用最适合它那项任务的模型。
为什么单体 agent 做不到这件事:因为它只有一个模型调用, 那一次调用要同时干判意图和写回答,所以只能按最难的那件事选模型。 拆开之后,简单的那几步才有资格降级用便宜的。
判断(我们的,不是书里的): 这条「拆开反而省钱」成立有一个前提, 书没有明说:拆出来的步骤里,得有相当一部分是真的简单。 如果你把一个复杂任务拆成五个同样复杂的子任务,那就是五次完整模型调用,确实贵五倍。 拆分省钱的真正来源,是它把「简单」从「复杂」里分离了出来。 如果错,会错在: 如果你的小模型在判意图这一步经常判错, 后面纠错的代价(走错支线、重跑一遍)会把省下来的钱吃回去,甚至倒亏。 判据是:拿一批真实问题量一下小模型判意图的准确率——低于九成,这笔账就得重算。
6. 图像那一支:最小的那个 agent
这一节讲主走查第 ①② 步,而它值得讲是因为书主动澄清了一个容易误解的地方。
① 图片 → 交给一个专门给图片写文字描述的程序
→ 产出一个短标签:`trail hiking boots`
② 这个标签 + 用户的文字 → 拼成:`trail hiking boots waterproof`
③ 拼好的这段文本,**原样交给搜索那一支**
图说:**注意第 ③ 步——它没有任何新的搜索逻辑。**
这个「图像 agent」干的全部事情,就是把图片变成更好的搜索输入。
书专门澄清了一件事,而这一句很容易被读漏:
给图片写描述这一步,发生在这个 agent 被调用之前。 是你的应用代码或者一个独立的预处理步骤去调用那个视觉程序; 这个 agent 自己不选也不调视觉模型,它只接收一个描述字符串(就是一段纯文字)作为输入。8
为什么这个澄清有价值: 它示范了拆分的一种正确姿势 ——这个 agent 的职责被缩到了极小(拼一个更好的查询词), 它不拥有视觉能力,只消费视觉能力的产出。
7. bug 长在接缝上
这一节是全章最实用的一块,也是它真正的可靠性落点。
先看现象:每个 agent 都测过了,系统还是错的
书的原话:bug 和失败发生在接缝处——agent 之间传信息的时候、 状态被更新的时候、流程变复杂的时候。9
书还把这一点和传统测试对照了一下:
不像传统的单元测试只验证孤立的函数, 多 agent 的测试必须验证编排这一层:确保 agent 之间沟通有效、 状态在组件之间正确流动,以及单个 agent 失败时系统优雅降级。10
五类测试,以及书给的具体测例
这是全书最实用的一张清单,我们逐条给出可以照抄的测例。
| 类别 | 测什么 | 书给的具体测例 |
|---|---|---|
| ① 混合请求与多模态(多模态指一次输入里同时有文字和图片这类不同形式的内容) | 编排的那一层能不能识别复杂需求、路由到多个 agent,并且把全部关键条件都保住 | 图片(棕色皮质徒步靴)+ 文字(「要防水的、150 美元以下,退货政策是什么?」)→ 断言最终回答里同时含 boot / waterproof / return / $150 |
| ② 意图含糊时的路由 | 需求不清楚时,它能不能做出合理的决定 | 「我需要点保暖的东西去徒步」→ 该走搜索;「要是不合脚怎么办?」→ 该推断出这是政策语境;「你能帮我吗?」→ 该给出引导,而不是困惑 |
| ③ 单个 agent 挂掉时的韧性 | 一个组件坏了,系统还能不能维持服务质量 | 把搜索那一支换成一个直接抛异常的假函数;断言回答里出现「抱歉」或者「无法」,但不许出现「error」这个词;再测部分失败——问答挂了但搜索还在,搜索结果必须保住 |
| ④ 状态流动与信息保全 | 关键需求能不能穿过整条流水线不丢 | 「我要 10 码男士防 水靴,120 美元以下」→ 检查 ["size 10","men","waterproof","$120","boot"] 这五项,保住率必须 ≥ 0.8;另外测状态污染——先问红色冬季夹克,再问配送政策,第二个回答里不许出现「红色」或「夹克」 |
| ⑤ 回归 | 加了新功能有没有弄坏旧的 | 书给的规矩:为你找到的每一个 bug 写一条测试。把可靠性变成习惯 |
第 ③ 类那条断言,值得单独讲
走查第 ⑨ 步:
把搜索那一支替换成一个直接报错的假函数
▼
系统仍然要给用户一个回答
▼
断言 1: 回答里有「抱歉」或「无法」 ← **它承认这次没办成**
断言 2: 回答里**没有「error」这个词** ← **技术细节不许漏给用户**
图说:**第二条断言才是精髓。** 它把「优雅降级」这个模糊的要求,
变成了一条机器可以判的规则:**技术词汇泄漏到用户面前,就算失败。**
(这两条断言是书里的原样。)
这条断言和第 15 章那条「给人看的一句话是你写的」是同一件事的两端: 那边规定工具该返回什么,这边规定用户最终不该看到什么。
第 ④ 类那个「状态污染」也是一条硬测例
第一轮: 用户问「有红色的冬季夹克吗?」 → 系统答,白板上留下了「红色」「夹克」
第二轮: 用户问「你们的配送政策是什么?」
▼
断言:第二轮的回答里**不许出现「红色」或者「夹克」**
图说:**共享状态是这一章最大的好处,也是它最大的风险。**
白板方便所有人读写,也意味着**上一个话题的残留会渗进下一个话题的回答**。
这条测试就是专门防它的。
8. 两种框架,其实是两种心智模型
这一节讲选型,但书讲的不是功能对比,是「你得像谁一样思考」。
一种框架要你像软件工程师那样思考。 你定义显式的状态、节点和边, 本质上是在画一张「信息怎么在系统里流动」的流程图。 你精确控制谁在什么时候和谁沟通。
另一种要你像管理者那样思考。 你不画流程图,而是给每个 agent 定义角色、目标和背景故事, 很像给一个团队写岗位说明书。 agent 按各自的分工自主协作,协调的细节由框架处理。11
| 画流程图的那一种 | 写岗位说明书的那一种 | |
|---|---|---|
| 心智模型 | 流程图 / 状态机 | 岗位说明书 / 委派 |
| 适合 | 复杂分支(A 可能按中间结果去调 B 或者 C)、有循环的流程(重试、回头澄清)、多人共建的共享基础设施 | 快速做原型、大体线性的流程(先搜索、再分析、再回答) |
| 代价 | 前期代码多、学起来陡 | 代码少、默认值合理,但你很难看清 agent 之间到底怎么互动的 |
「岗位说明书」那一种具体长什么样,书给了同一个购物助手的另一种写法: 三个带人设的角色——「商品专家」(背景故事写着「你是户外装备专家, 有多年帮顾客找到他们真正需要的东西的经验」)、「客服代表」、 以及「回复协调员」(它的背景故事里明确写着「你从不提及内部流程或者其他 agent」)。
最后那句人设很有意思:它用一句自然语言,达到了上一节第 ③ 类测试用断言达到的效果。
书自己的结论,值得照搬
最重要的不是框架,而是理解这些模式:意图分析、agent 专门化、状态管理、 错误处理、回答综合。掌握这些,你用任何工具都能建多 agent 系统。12
书还点了另外三个框架的名: 一个来自微软、专注让 agent 之间能互相对话; 一个强调 agent 的自主性和自我改进;一个是流水线式的,在检索和搜索场景里流行13。
而第 13 章那一章末尾还给了一张更宽的格局表(五个生产级选项各自的侧重: 图式编排 + 检查点 + 人在环(流程走到关键处停下来等人点头再继续)/ 干净的 agent 间交接与内建追踪 / 安全优先的工具调用链 / 基于角色的最快原型路径 / 支持 agent 之间通信协议的那一个)14。 我们把它挪到这里,是因为只有在这一节的对照里它才有意义。
9. 作者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 一句话里藏着三种不同的智能 | 给了一句具体的用户请求,并逐条拆出三种需求 |
| 关键词判意图不可靠 | 和第 13 章那条护栏批评互相印证,书两处独立给出了同一个诊断 |
| 大小模型分工能省钱 | 给了具体的分工点(判意图用小、合成用大),但没有给任何成本数字 |
| bug 长在接缝上 | 给了五类测试和每一类的具体断言——这是全章证据最扎实的一块 |
| 保住率 ≥ 0.8、不许出现「error」 | 两条可以直接跑的断言 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 单体 agent 的三个症状 | 一组经验观察,没有对照实验 |
| 多 agent 的四条收益(模块化 / 可扩展 / 可靠 / 可维护) | 一张标准的架构收益表,任何拆分都能这么说,没有量化 |
| 两种框架的适用场景对照 | 一张经验表,书没给选型失败的案例 |
| 「保住率 0.8」这个门槛 | 一个拍出来的阈值,书没说为什么是 0.8 而不是 0.9 |
10. 边界与局限
-
没有讲 agent 之间怎么并行。 主走查里搜索和政策是顺序走的, 可它们互不依赖,本可以同时跑。 书完全没提并行,而这在延迟上是大头;
-
没有讲拆到多细才合适。 三个 agent 还是十个?书给了拆分的好处, 没给「拆过头」的坏处——而拆得越细,接缝越多,而 bug 恰恰长在接缝上;
-
误差级联在这一章消失了。 第 12 章说「每步 85% 走十步只剩两成」, 而多 agent 恰恰增加了步数。 书没有回过头来算这笔账,这是全书链条上一个明显的断点;
-
那个「保住率 ≥ 0.8」的门槛没有依据。 五项条件丢一项就算通过—— 可如果丢的是「120 美元以下」,用户拿到的就是一堆买不起的靴子;
-
共享状态怎么清理没讲。 第 7 节那条「状态污染」测试指出了问题, 但书没有讲该在什么时候把白板擦掉、擦哪几格;
-
框架名和模型名会过时。 这一章提到的框架格局、模型型号, 一年之内会换一批。要记的是那五个概念、那五类测试,和「bug 长在接缝上」这句话。
11. 可带走的
全章那条走查,一行写完: 靴子照片 → 图像描述程序产出 trail hiking boots →
和用户文字拼成 trail hiking boots waterproof → 小模型判意图返回
{search_needed: true, qa_needed: true} → 条件边走「两样都要」那一支 →
搜索取到 3 件 → 结果文字里出现 return / warranty,强制把「要问答」置真 →
政策那一支取到退货条款 → 换完整模型合成一条回答 →
最后把搜索换成报错的假函数,断言回答里有「抱歉」但没有「error」。
- 单体 agent 的三个症状: 上下文被无关信息填满、回复前后不一致、 加新能力得重写整个系统;
- 一句普通的 顾客请求里可能藏着三种不同的智能: 找货、懂规则、把两份答案写成一条话 ——它们要的能力不一样,所以一个提示词兼顾不了;
- 串起多个 agent 只要三样东西: 一块所有人都能读写的共享状态、 一个个节点、以及边;会看状态决定走哪条的边叫条件边;
- 条件边是唯一真正新的东西——它把「下一步走哪儿」从写死的代码挪到了运行时的数据上;
- 判意图不许用关键词表,用函数调用,并且强制模型必须调; 模型没调时要有一条保守的默认路径;
- 用函数调用而不是解析自由文本,理由是格式有约束、不会多写少写;
- 关键词不能做主判断,但可以做「宁可多做一步」的补救(搜索结果里出现 warranty 就强制走问答);
- 拆开反而省钱: 判意图用小模型、合成回答用完整模型。 单体 agent 做不到,因为它只有一次调用,只能按最难的那步选模型;
- 拆分的一种正确姿势:让每个 agent 的职责尽可能小。 那个图像 agent 不拥有视觉能力,它只消费视觉能力的产出;
- 最该记住的一句:bug 不长在单个 agent 里,长在它们之间的接缝上;
- 五类测试: 混合请求的路由、意图含糊时的判断、单个 agent 挂掉时的优雅降级、 状态流动与信息保全、回归;
- 「优雅降级」可以被测: 回答里要有「抱歉」,但不许出现「error」这个词;
- 共享状态最大的风险是污染: 先问红夹克再问配送政策, 第二个回答里不许出现「红色」;
- 两种框架是两种心智模型: 一种要你画流程图,一种要你写岗位说明书;
- 书自己的结论:重要的不是框架,是那五个模式——意图分析、agent 专门化、 状态管理、错误处理、回答综合。
12. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 开场:靴子照片加两句追问 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:11(搜「texts a photo of their hiking boots」) |
| 上一章的工具是孤立的 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:17(搜「they're also isolated」) |
| 单体 agent 的三个症状 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:30(搜「mediocre at everything」) |
| 一句话里的三种智能 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:53(搜「three distinct types of intelligence」) |
| 五个概念与多出来的五件事 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:79(搜「Unlike simple function」) |
| 「不要用脆弱的关键词匹配」 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:102(搜「brittle keyword matching」) |
| 用 函数调用而不是解析 JSON,以及兜底 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:140(搜「instead of JSON parsing」) |
| 大小模型分工 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:518(搜「for straightforward tasks」) |
| 启发式回补那五个词 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:613(搜「sizing」) |
| 图像那一支的三步与那条澄清 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:740(搜「captioning model」) · text/11-ch08-chapter-8-multi-agent-systems.txt:766(搜「no new search logic」) |
| 多 agent 的四条收益 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:825(搜「Modularity」) |
| bug 长在接缝上 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:850(搜「happen at the seams」) · text/11-ch08-chapter-8-multi-agent-systems.txt:863(搜「orchestration layer」) |
| 「有抱歉但没有 error」那条断言 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:1034(搜「sorry」) |
| 保住率 ≥ 0.8 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:1120(搜「size 10 men's waterproof boots」) · text/11-ch08-chapter-8-multi-agent-systems.txt:1133(搜「preservation_rate」) |
| 两种框架的心智模型 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:1221(搜「think like a software engineer」) |
| 另外三个框架、以及最后那句结论 | Chapter 8: Multi-Agent Systems | text/11-ch08-chapter-8-multi-agent-systems.txt:1442(搜「Other frameworks worth exploring」) · text/11-ch08-chapter-8-multi-agent-systems.txt:1452(搜「isn't the framework」) |
| 五个生产级框架的格局 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1225(搜「agent framework landscape」) |