手记

建立 Agent 系统的复杂度、分层与协作地图。

一个产品接入大模型、知识库和工具后，是不是 Agent？答案取决于谁拥有下一步决策权，而不是组件数量。代码规定“先分类，再查询，最后生成”是 Workflow；模型能根据观察动态决定查询、追问、修改计划或停止，更接...

团队常把 RAG、工具、Memory、Multi-Agent 和 A2A 一次塞入方案，在需求尚未验证时就承担分布式系统成本。本章用复杂度阶梯回答：下一层到底新增什么能力与责任？

“这个需求要不要 Multi-Agent？”问得太早。正确顺序是先确定任务、验收和风险，再决定控制、推理、上下文、拓扑与运行时。

一张“Agent A → Agent B”的箭头图常混合四件事：谁决定调用、传了什么业务数据、模型看到了什么、系统状态如何变化。混在一起后，权限泄漏、恢复错误和结果归属都难以发现。

判断什么时候需要普通 AI 功能、Workflow、Single Agent 或 Multi-Agent。

区分用户交互界面与系统执行架构，避免把聊天框误认为 Agent。

一次调用同时研究、起草、校验和润色，提示词会承担过多目标，任何局部错误也难以定位。Sequential 把稳定任务拆成有顺序、有契约的阶段。

不同请求需要不同能力与政策，却都进入同一提示词，导致上下文臃肿、答案不稳定。Routing 先判断类别，再选择有限分支。

多个互不依赖的子任务串行执行会放大等待；单一回答也可能缺少多视角覆盖。Parallelization 同时运行独立工作，再合并结果。

一次生成很难稳定满足可明确检查的质量标准，但让生成器无限自我修改又会循环。Evaluator–Optimizer 把生成和评价分离，并设置有界反馈回路。

真实产品不是单一 pattern，而是线性步骤、条件分支、并行汇合、有界循环与降级的组合。缺少组合语义会让错误路径成为隐式代码。

Workflow 稳定但覆盖有限，Agent 灵活但不确定。团队需要基于任务证据选择，而不是把 Agent 当作默认升级方向。

开放任务的下一步依赖工具返回，无法在运行前写成完整路径。ReAct 让模型在行动与观察之间迭代更新决策。

只画一个圆环无法实现可运营 Agent：必须明确每轮读取什么、产出什么、谁执行、状态何时提交。

Agent 完成后可能遗漏约束或未利用已有证据。Reflection 在最终提交前重新检查轨迹与候选结果。

生成者容易重复自己的盲点。独立 Critic 用不同指令、上下文或模型评价候选，再由 Reviser 定向修改。

模型能提出行动意图，但不能成为执行权限本身。若工具只是任意函数入口，Prompt 注入和参数错误会直接变成外部副作用。

Agent 不知道何时停，就会过早回答、反复搜索或在信息不足时猜测。停止是一等架构能力，不是 Prompt 末尾一句话。

ReAct 一步一决策容易局部贪心，用户也难以预判长任务范围。Plan-and-Execute 先形成显式步骤，再按计划执行。

同一模型一边规划一边执行会混淆全局目标与局部工具细节。角色分离让计划可校验、执行可替换。

静态计划遇到新证据、工具失败或目标变化后会失效。Replanner 根据已完成事实更新剩余工作。

任务列表只表达顺序，无法说明哪些工作可并行、哪些结果阻塞后续，也无法可靠传播取消。

Planner 给出的第一份计划可能不可执行、过贵或忽略关键约束。执行前需要硬校验，必要时比较候选。

消息历史无法可靠回答完成了什么、产物在哪里、还剩多少工作。长任务需要独立于对话的进度账本。

模型不是缺少所有信息，而是缺少当前决策所需的正确信息。把全部历史塞入上下文会引入噪声、泄漏和成本。

一次给出所有工具说明、文档和历史会稀释当前目标。Progressive Disclosure 按需逐层开放。

组件直接转发整段对话会传播噪声和隐私，也让接收者不知道什么是要求、证据或猜测。

多 Agent 共享全部历史会造成角色干扰、敏感数据横向扩散和上下文竞争。

长任务轨迹不断增长，成本上升且早期约束可能被挤出。Compression 将历史转成可继续工作的紧凑状态。

Agent 看到一段内容却不知道来源、时间、所有者和可信度，既无法引用，也无法正确执行权限与注入防护。

当前任务的计划、最近观察与临时变量需要跨步骤保留，但不应永久记住。

Agent 需要利用过去任务经验，却不能把每次对话都当永久事实。

跨任务稳定事实与偏好需要被检索，但来源和有效期必须清楚。

系统需要复用成功做法，但不能让一次偶然轨迹自动变成高权限流程。

多 Agent 需要共享成果，但全局共享会泄漏数据并造成角色互相污染。

记忆价值取决于何时读、什么能写、何时忘，而不取决于存储量。

长任务的大文件和中间成果不适合反复塞进消息，也不应被自由摘要替代。

单 Agent 在工具过多、上下文过长、专业目标冲突或独立子任务较多时会成为瓶颈，但拆 Agent 本身并不创造价值。

Multi-Agent 容易在 Demo 中显得聪明，却可能把一个 Prompt 问题放大成分布式协调问题。

工具函数、Prompt 模块和独立 Agent 常被混为一谈，导致系统宣称 Multi-Agent 却没有真实决策边界。

角色只写成“你是专家”无法建立可靠分工，容易角色漂移、工具越权和重复劳动。

多个 Agent 都能输出时，用户会收到重复、矛盾或无人负责的答案。必须有唯一可解释的最终答案所有权。

Multi-Agent 可能节省单个上下文，却增加重复前缀、通信和合成；一个错误委派还会沿链级联。

主 Agent 需要专业帮助，但仍需保持用户关系、全局目标和最终答案控制权。

多个 Specialist 需要统一分解、委派、预算、合成和停止，否则会重复工作或无人负责。

请求可能涉及一到多个独立领域；串行 Supervisor 会增加等待，单选 Router 又可能漏掉多意图。

某些 Specialist 需要直接与用户连续交流；Manager 代传每句话会损失细节、增加延迟和上下文。

一些任务需要多个角色基于彼此结果迭代，而不是独立返回一次；需要定义谁下一位发言。

中心 Supervisor 可能成为瓶颈；在角色网络中，当前 Agent 可更快判断应该把控制交给哪个邻居。

真实产品常同时需要入口路由、后台专业计算、直接 Handoff 和质量评价，单一 Pattern 无法覆盖。

单层 Supervisor 的 Worker 太多、上下文过载时，需要把控制分成全局与团队两级。

多个 Supervisor 形成树状委派，必须定义父子责任、结果回传和全局预算。

大型目标包含多个内部协作方式不同的团队，单一 Worker 接口无法表达。

任务分解深度在运行前未知时，Agent 可能递归创建子任务，但必须保证收敛。

团队需要根据局部信息灵活执行，同时全局必须控制目标、预算、策略和承诺。

完整上下文跨层复制会指数膨胀，过度摘要又会丢失用户约束和证据。

Agent 之间需要点对点传递任务或结果，并明确发送者、接收者与关联任务。

多个组件需要读写同一任务事实，但自由覆盖会导致竞争和不可恢复状态。

多个 Specialist 异步贡献线索，后续角色需要基于公共成果继续，而非互相点名。

组件不应知道所有下游，但任务状态变化需异步通知多个消费者。

Agent 需要保留局部草稿和观察，同时向外只暴露协作必需结果。

系统常用一条消息同时承担通知、当前事实和大文件，导致恢复和版本混乱。

通信边决定信息、成本和故障如何传播；全连接并非默认最灵活方案。

AI 应用需要以统一方式发现和调用外部工具、资源与提示，同时让应用保留上下文、同意和安全控制。

独立团队或厂商的 Agent 需要在不暴露内部工具、Memory 和实现的情况下协作。

两种协议都涉及 Agent，很容易误选：把独立 Agent 当工具会丢失任务生命周期，把普通工具当 Agent会增加复杂度。

Client 在调用前需要知道远程 Agent 是谁、在哪里、支持哪些接口和技能，以及如何认证。

自然语言消息、长任务状态和最终文件混在一起时，客户端无法可靠追踪、恢复和交付。

协议互通不等于可信。系统必须区分用户、Client、Remote Agent、Server 和下游 API 的身份与权限。

Agent 工作从毫秒回答到数小时任务，单一同步请求会超时，纯轮询又让体验迟钝。

控制路径需要在可预测与适应性之间分配，而不是全交给代码或模型。

具有明确依赖的任务需要并行和拓扑调度，同时禁止循环。

Agent 流程包含条件分支、回边和动态路径，DAG 不足以表达。

产品必须明确任务处于什么状态、允许哪些操作以及如何从失败恢复。

组件需异步响应已发生事实，且生产者不应等待或知道所有消费者。

评审、重规划和对话需要受控回边，但普通 Workflow 的循环常隐藏在代码中。

长任务跨进程重启、用户等待与外部超时，内存循环无法保证恰好继续。

多 Agent 不能只靠一句“你负责研究”；任务依赖、完成和回传必须可验证。

把任务分给第一个可用 Agent 会造成能力、权限、数据域或成本不匹配。

多个任务争用有限模型、工具和人力，需要可解释顺序与公平性。

无限并行会触发模型限流、数据库压力和成本峰值；过低并发又浪费时间。

请求速度超过处理能力时，隐藏排队会让超时与成本失控。

多个 Agent 结果冲突时，多数票看似简单，却可能放大同源错误且忽略证据。

用户取消上层任务后，下游仍运行会浪费资源或产生副作用；上游失败也应阻断依赖项。

Agent 的不确定性、风险或价值判断需要人参与，但每一步都审批会消灭自动化收益。

高风险动作需要在执行前展示准确预览并获得不可混淆的授权。

Agent 无法继续、用户要求人工或风险超界时，需要带上下文转给人，而不是让用户重述。

纯 Agent 自主或纯人工命令都不适合共同编辑、研究和决策。

Prompt 规则会被上下文干扰，且无法单独承担组织政策与副作用控制。

Agent 的能力清单不应等于用户权限，连接凭据也不应自动授予所有动作。

复杂 Agent 的决定、数据流和责任若只留在聊天中，无法解释、纠错或满足治理。

Agent 失败不只有答案错误，还包括决策、工具、状态、通信、权限、运行时和产品承诺失败。

瞬时故障可重试，但语义错误和副作用盲重试会放大损害。

没有 deadline 的 Agent 会无限等待；取消不传播则后台仍消耗和执行。

Agent 可能重复行动、角色互相交接或计划震荡，max_steps 只能限制损失不能识别原因。

重试、恢复和重复消息可能让发送、扣款、删除执行多次。

并行或多 Agent 系统中部分成功是常态，整单回滚常不可行。

多个 Agent 新增角色漂移、错误委派、上下文丢失、冲突、群体偏差、级联错误和通信爆炸。

进程或依赖故障后，从头运行浪费成本且可能重复副作用。

没有统一运行模型，团队只能看聊天文本，无法定位模型、工具、Handoff、等待和错误的因果关系。

最终答案看似不错不代表用户目标完成；需按任务定义输入、环境、成功和副作用。

Agent 可能偶然得到正确答案，却调用危险工具、走冗余路径或忽略澄清。

工具与转移是高影响决策，需要独立测量选择、参数、权限和结果使用。

最终输出无法说明 Specialist 是否有贡献、协调是否浪费或错误如何级联。

上线前需要可重复比较 Prompt、模型与架构，但随机 Demo 不能发现回归。

离线集无法覆盖真实分布、供应依赖和用户期望，需要安全地从线上学习。

总平均成本无法解释哪个角色、步骤或重试值得，质量提升也可能被失败任务成本掩盖。

框架选择首先是架构选择。相同的“支持多 Agent”，可能分别意味着图节点、角色团队、工具调用或控制权移交，产品的可控性与故障形态完全不同。

LangGraph 的核心不是“很多 Agent”，而是持久化的 StateGraph：节点读取和更新状态，边决定下一步。显式控制流、检查点和可恢复执行适合长任务、审批与复杂分支。

AutoGen 让“会话中的多个角色”成为易理解的协作模型，团队、选择器、群聊和消息驱动适合探索协作行为。Microsoft Agent Framework 进一步把 Agent 抽象、会话状态、中间件、遥测和图工作流放进统一的企业运行模型。

Crew 强调有目标、角色和任务分工的 Agent 团队；Flow 强调带状态、事件和分支的可控业务流程。产品级用法通常不是二选一，而是让 Flow 管住生命周期，在某个节点调用 Crew 完成开放式协作。

OpenAI Agents SDK 以 Agent、tools、handoffs、guardrails、sessions 和 tracing 为核心。它不强迫使用图；团队可以让代码决定编排，也可让模型在工具调用和 Handoff 中决定下一步。

Google ADK 区分依赖模型推理的 LLM Agent 与负责确定性控制的 Workflow Agent。Sequential、Parallel、Loop 等组合原语让团队把确定流程写清，再在合适节点引入模型自主性，并可通过多 Agent 和 A2A 扩展。

不存在总体最好的框架，只有对当前风险、团队和生命周期更合适的组合。选型顺序应是任务确定性→持久化与审批→协作形态→生态与团队能力→退出成本，而不是先挑框架再迁就产品。

框架不同，但稳定的产品架构概念应能互相映射：任务状态、阶段、角色、工具、Handoff、审批、恢复和观测。如果系统只能用某个类名解释，通常还没有形成清晰架构。

第一版不需要自主 Agent。用户真正要的是一份结构完整、来源可追踪、按时返回的报告；固定流程已经能验证需求、数据源和质量标准，也提供以后比较的基线。

基线暴露三个瓶颈：不同报告类型需要不同模板，独立来源串行检索太慢，草稿质量只能人工发现。Router、Parallel 和 Evaluator 分别解决适配、时延和质量反馈，不需要开放式 Agent 循环。

部分研究问题需要根据刚发现的信息继续选择查询、打开文件或补证据，固定检索分支会不断膨胀。版本 3 只把“探索研究”阶段替换为一个 ReAct Agent，其余流程、质量门和发布仍保持确定性。

当报告跨多个公司、地区和时间段时，单个 ReAct Agent 容易局部探索过深、遗漏任务或重复劳动。Planner 提供全局任务图，Executor 完成原子任务，Replanner 只根据新证据修订未完成部分。

随着计划和工具轨迹增长，模型会被无关内容干扰；重复客户研究又在浪费已验证事实。版本 5 把上下文选择、短期任务状态、长期知识和最终产物分开治理。

当研究、数据分析、风险判断和编辑需要不同工具、提示、权限与评估标准时，单 Agent 的上下文和权限过宽。Supervisor 负责分解、委派、合并和预算，Specialist 只完成边界清晰的专业任务。

有些任务不是“主 Agent 调专家再回答”，而是用户需要与合规或行业专家持续澄清；同时专家数量增加后，单一 Supervisor 成为瓶颈。Handoff 解决会话所有权转移，层级团队解决管理跨度。

到版本 7，路由、规划、专家团队、质量返工和人工批准已经形成复杂生命周期。继续散落在回调和提示词中会难以理解与恢复，因此用状态图统一业务阶段，而不是把所有 Agent 行为改写成图。

当数据工具由不同团队维护、某些专家由外部服务提供时，进程内函数和本地子 Agent 不再够用。MCP 统一 Agent 对工具与资源的访问，A2A 统一 Agent 对远程 Agent 任务与产物的协作，两者解决不同边界。

最终升级不是再增加一个 Agent，而是让整个系统在真实故障、敏感操作和模型变化中仍兑现产品承诺。可靠性处理运行错误，HITL 管理决策边界，可观测性解释发生了什么，Evals 判断系统是否真的变好。

用最小 Harness 理解模型调用、工具执行、上下文更新和停止条件。