大家好，我是十三！欢迎来到十三Tech。
继续看《Agent 设计模式之美》，第三讲里有个词让我停了很久：拓扑。
刚看到这个词，我其实挺有兴趣。一个新概念如果真能帮我们把问题说清楚，就值得认真学；同时也要追问一句：它最后能不能落到真实项目里，帮我们做出更稳定的设计判断。
这一讲看完后，我觉得它很实用。因为它提醒了我一件事：设计 Agent 时，不能只问它会什么，还要问这些能力到底怎么跑。
这个差异很小，却影响落地。
如果你也做过一点 Agent 或工作流，大概率会遇到类似场景：需求一来，先拖几个节点，接一个模型，再接几个工具。看起来完整了，可一旦任务变复杂，延迟、成本、失败恢复就一起冒出来。
这篇是我读完第三讲后的阶段性理解：功能拓扑和执行拓扑不是两个新名词，而是一套避免"先搭流程后补逻辑"的设计提醒。
一、先别急着画流程，先问系统缺什么能力
过去做服务端系统时，我很习惯先拆模块。
订单模块、库存模块、支付模块、通知模块，每个模块有清晰职责，再通过接口协作。这个拆法在确定性系统里很好用，因为我们大多数时候知道输入是什么，输出是什么，异常怎么兜底。
到了 Agent 场景，问题变了。
一个 Agent 系统不是只有"模块"，它还要处理感知、记忆、推理、行动、反思、协作、治理这些能力。感知不只是拿到输入，记忆不只是存数据，行动也不只是调接口。
所以这一讲里我最先记住的，是功能拓扑这个视角。
功能拓扑回答的是：这个系统到底需要哪些能力组合。
我把它理解成一张能力体检表。不是上来就说"我要一个多 Agent 系统"，而是先问：
| 设计前容易问的问题 | 更有用的问题 |
|---|---|
| 要不要做多 Agent | 任务是否真的需要协作能力 |
| 要不要加记忆 | 历史信息是否会影响当前判断 |
| 要不要加反思 | 结果质量是否需要自我校正 |
| 要不要接工具 | 行动是否有权限、回滚和审计边界 |
顺序很关键。
如果能力层没想清楚，执行流程画得再顺，也只是把不确定性藏进了连线里。真正上线后才发现，系统不是缺一个节点，而是缺一类能力。
这就像排查线上问题。接口慢了，不能只说"加机器"。你得先判断是数据库慢、缓存没命中，还是下游服务不稳定。Agent 设计也一样，先定位能力缺口，再谈怎么组织执行。
二、三圈结构：不要一上来就做复杂协作
课程里有一张能力栈三圈结构图，我看完后觉得挺适合贴在工位旁边。
这张图我会这样理解。
内圈是核心认知能力：感知、记忆、推理、行动。它们决定一个 Agent 最基本的理解和执行能力。
中圈是元认知能力：反思。它让系统不只是执行，还能回头检查结果、修正路径。
外圈是系统智能：协作和治理。它负责把单体能力扩展成可协作、可控制、可追责的系统形态。
这个层级给我的工程启发很直接：构建顺序要由内向外。
很多 Agent 方案看起来很完整，一上来就多角色分工，Planner、Executor、Reviewer、Critic 全都安排上。这个方向我愿意试，但真实调试时仍然要问清楚：是谁把上下文带偏了？是谁调错了工具？
所以我现在会多看一层。
如果系统连基本感知都不稳定，记忆也没边界，行动权限也没收住，就急着上协作，通常不是增强智能，而是在放大不确定性。
这有点像团队管理。一个人还没把职责、输入输出和交付标准搞清楚，就先拉十个人开会，最后不一定更高效。
Agent 也是这样。
协作不是复杂度的解药。很多时候，协作本身就是复杂度。
三、执行拓扑决定系统怎么跑
功能拓扑说清楚"系统要会什么"之后，才轮到执行拓扑。
执行拓扑回答的是：数据、控制和反馈，在这些能力之间怎么流动。
课程里给了六种很典型的执行拓扑：链式、路由、并行、编排、循环、层级。
我不想把它们当成概念清单背下来。更有用的理解方式，是把它们看成六种运行姿势。
链式像流水线，适合步骤清楚的任务，简单、可解释，但前面错了，后面大概率跟着错。
路由像分诊台，先判断任务类型，再分给不同处理路径。它的关键不是路由本身，而是分类标准要稳定。
并行像多个同事同时出方案，最后汇总比较。适合多路探索，但成本和延迟要算清楚。
编排像项目经理，中心调度者统一安排多个执行单元。它适合复杂任务拆解，也会让中心节点变成关键瓶颈。
循环像写文章反复改稿，生成、评审、修正，再生成。它能提升质量，但必须有退出条件。
层级像组织架构，主 Agent 负责分派，子 Agent 负责执行。它适合复杂分工，也最容易出现上下文传偏的问题。
你看，这些拓扑没有谁天然更合适。
真正的问题是：当前任务需要哪种控制流，能承担什么代价，又要留下什么观测点。
四、同一个目标，可以有完全不同的跑法
这一点是我觉得第三讲最值得反复想的地方。
同样是"生成一份技术方案"，可以有很多跑法。
需求很清楚，用链式就够了：理解需求、生成方案、补充边界、输出结论。
需求类型很多，先路由更合适：架构方案、产品方案、运营方案，不同路径用不同 Prompt 和工具。
目标是比较多个方向，可以并行：分别从成本、稳定性、研发效率角度出方案，再汇总。
质量要求很高，可能要循环：先生成初稿，再评审，再修正，直到满足质量门槛。任务特别复杂，才可能引入编排或层级。
这背后其实是一个很朴素的工程判断：拓扑选择不是审美问题，是成本、质量、延迟和可控性的权衡。
过去我做系统设计时，经常会问一个问题：这个复杂度值得吗？
现在看 Agent，也应该这么问。
多加一个反思循环，质量可能更高，但延迟和成本也会上去。多加一个角色，分工可能更清晰，但上下文传递和责任归属也会更难。
所以我现在会少用"某某拓扑更强"这种判断。
它是不是新、是不是酷，都不是第一优先级。匹配不匹配，才是关键。
五、我现在会怎么用这套方法
如果以后设计一个 Agent 小系统，我会强迫自己先走三步。
第一步，先画能力层。
这个系统到底需要感知、记忆、推理、行动里的哪几类能力？有没有反思需求？是否真的需要多 Agent 协作？工具调用的治理边界在哪里？
第二步，再画执行流。
任务是顺序推进、按条件分流、多路探索、中心编排，还是需要循环修正？每一种跑法的成本、延迟、失败点在哪里？
第三步，最后才选模式。
先不急着说"我要上多 Agent""我要加反思""我要做层级"。这些都是手段，不是问题本身。
这套顺序对我很有帮助。因为它把 Agent 设计从"套一个流行工作流模板"，拉回到了更熟悉的工程判断里：先识别问题，再选择结构，最后评估代价。
我还不敢说自己已经能把每一种拓扑都用得很熟。但至少第三讲让我确认了一件事：Agent 系统的复杂度，不能靠更复杂的流程图解决。
流程图只能表达运行方式，不能替你回答能力边界。
真正可靠的 Agent 设计，不是画出最复杂的流程，而是让每一种能力都跑在它该跑的位置上。
关于十三Tech All in AI Agent方向的架构师，专注AI工程实践。 相信AI是程序员的最佳搭档，帮助每一位开发者驾驭AI。
联系方式：569893882@qq.com GitHub：@TriTechAI