无标题从 Prompt 工程师到 Agent 架构师：万字解析多智能体协同（Multi-Agent）底层逻辑

如果你还在研究“怎么写一个更好的 Prompt”可能已经开始进入 Agent 应用的下半场了。真正复杂的 AI 系统往往不是一个 Agent 一个 Prompt 就能解决的。当任务开始出现角色分工、任务依赖、上下文共享、工具调用、异常重试、结果验证以及多个 Agent 之间的博弈时本质上已经进入了Multi-Agent System多智能体系统的范畴。很多人第一次接触 AutoGen、CrewAI 这类框架时会把它理解成Agent A → Agent B → Agent C但这只是表面。真正需要研究的是┌──────────────┐ │ Orchestrator │ └──────┬───────┘ │ ┌────────────┼────────────┐ ↓ ↓ ↓ Researcher Coder Reviewer │ │ │ └────────────┼────────────┘ ↓ Shared Context ↓ State / Memory ↓ Final Decision这篇文章不讨论“什么是 Agent”这种入门问题。我们直接从架构师的视角拆解Agent 到底应该怎么定义任务怎么编排上下文怎么共享多个 Agent 意见不一致怎么办什么时候应该使用 Multi-Agent什么时候单 Agent 反而更合理一、Multi-Agent 真正解决的不是“多人聊天”这是很多开发者最容易理解错的地方。一个普通的 LLM Workflow用户 ↓ LLM ↓ 工具 ↓ LLM ↓ 结果本质上还是一个中心化决策系统。而 Multi-Agent 更接近Task ↓ Task Planner ↓ ┌───────────┼───────────┐ ↓ ↓ ↓ Researcher Coder Analyst ↓ ↓ ↓ └───────────┼───────────┘ ↓ Reviewer ↓ Aggregator ↓ Result这里发生了一个非常重要的变化模型不再只是一个“回答问题的组件”而开始成为一个具有角色、状态、工具和目标的执行节点。因此一个完整 Agent 通常至少包含Agent Role Goal Instructions Memory Tools State Policy Output Contract例如researcher Agent( roleSecurity Researcher, goal分析目标系统的安全风险, tools[ search_tool, document_tool ], output_schemaSecurityFinding )注意这里真正重要的不是roleSecurity Researcher而是后面的tools state output_schema policy因为到了工程阶段Agent 的核心已经从 Prompt 转变成了可控的状态机 LLM 决策器 工具执行器。二、Agent 角色定义不要把角色理解成一句 Prompt很多 Multi-Agent 项目第一版通常是这样写的你是一个程序员。 你是一个产品经理。 你是一个测试工程师。然后程序员 → 产品经理 → 测试工程师看起来像 Multi-Agent。实际上很可能只是三个 Prompt 串起来了。真正的 Agent Role Definition 应该至少包含五个维度。1. Identity定义 Agent 是谁。Security Researcher Code Reviewer Data Analyst Planner Executor2. Objective定义 Agent 的优化目标。例如目标 发现代码中的安全风险。但更合理的是目标 在不修改业务逻辑的情况下 最大化发现高置信度安全问题的数量。目标越具体Agent 的行为边界越清晰。三、最容易被忽略的Agent 的权限边界一个成熟 Multi-Agent 系统必须考虑这个 Agent 到底能做什么例如Researcher ↓ 只能搜索和读取资料 Coder ↓ 可以修改代码 Reviewer ↓ 只能读取代码和生成审查报告 Executor ↓ 可以执行指定工具因此可以把 Agent 权限抽象成class AgentPolicy: allowed_tools [] allowed_actions [] max_iterations 10 max_token_budget 8000例如researcher_policy AgentPolicy( allowed_tools[ search, document_reader ], max_iterations5 )这其实已经非常接近传统软件工程里的RBAC Capability Security Execution Policy这也是为什么真正的 Agent 系统不能只研究 Prompt。四、Multi-Agent 的核心任务编排如果说 Agent 是“人”那么 Orchestrator 就是“项目经理”。它负责解决谁先做 谁后做 谁依赖谁 什么时候并行 什么时候停止 失败以后怎么办这是 Multi-Agent 系统最核心的部分之一。五、三种典型任务编排模式1. Sequential串行编排最简单A ↓ B ↓ C ↓ D例如Researcher ↓ Analyst ↓ Writer ↓ Reviewer代码可以抽象成result researcher.run(task) result analyst.run(result) result writer.run(result) result reviewer.run(result)优点简单可预测容易 Debug缺点也非常明显吞吐量低。如果A 10s B 10s C 10s那么整体至少需要30s六、2. Parallel并行编排如果多个任务互不依赖┌→ Agent A │ Task → Planner ├→ Agent B │ └→ Agent C那么完全可以并行执行。例如results await asyncio.gather( researcher_a.run(task), researcher_b.run(task), researcher_c.run(task) )整体耗时从T A B C变成T ≈ max(A, B, C)这对于大规模 Agent 系统非常重要。七、3. Hierarchical层级式编排复杂系统更推荐Manager │ ┌────────────┼────────────┐ ↓ ↓ ↓ Research Coding Testing │ │ │ Sub-Agent Sub-Agent Sub-Agent这里 Manager 不直接完成所有任务。它负责Task Decomposition Task Allocation Progress Monitoring Result Aggregation Exception Handling这就是典型的Hierarchical Multi-Agent Architecture。例如class Manager: def plan(self, task): return [ research, implementation, testing ] def dispatch(self, tasks): ...八、真正复杂的是 DAG而不是简单流水线如果系统继续复杂A → B A → C B → D C → D D → E这其实已经可以抽象成Directed Acyclic GraphDAG例如A / \ B C \ / D ↓ E这时候 Orchestrator 实际上已经不再是简单的agent1() agent2() agent3()而是Task Graph Dependency Resolution Scheduler State Manager这也是 Agent Framework 从 Demo 走向生产环境的重要分界线。九、AutoGen / CrewAI 这类框架真正帮你解决了什么框架本身不是重点。重点是它们背后的抽象。一个 Agent Framework 通常需要解决Agent ├── Role ├── Instructions ├── Memory ├── Tools ├── State └── Communication Orchestrator ├── Scheduling ├── Routing ├── Retry ├── Termination └── Aggregation因此你研究 AutoGen 或 CrewAI 的时候不要只看agent xxx(...)真正应该追踪的是Agent 创建 ↓ Message 进入 ↓ Context 构建 ↓ LLM 调用 ↓ Tool Call ↓ State 更新 ↓ Message 路由 ↓ 下一 Agent这才是底层源码分析的主线。十、上下文共享Multi-Agent 最容易爆炸的地方单 AgentUser ↓ Context ↓ LLM非常简单。Multi-AgentAgent A ↓ Message ↓ Agent B ↓ Message ↓ Agent C ↓ Message问题来了Agent A 产生的信息要不要全部给 Agent B答案通常是不要。因为所有消息都共享会导致Context Window ↓ Token 数量暴涨 ↓ 成本增加 ↓ 噪声增加 ↓ 注意力稀释 ↓ 模型性能下降十一、Context Sharing 应该分层一个比较成熟的设计可以分成Global Context │ ├── Task Context │ ├── Agent Context │ ├── Shared Memory │ └── Execution StateGlobal Context整个任务共享{ task_id: T001, objective: ..., deadline: ... }Agent Context每个 Agent 独有{ agent_id: researcher, role: security researcher, private_memory: [] }Shared Memory多个 Agent 都可以访问Vector DB Document Store Knowledge Graph Cache例如Agent A ↓ Memory Store ↑ Agent B十二、不要让 Agent 直接共享全部聊天记录更合理的设计是Raw Messages ↓ Context Processor ↓ Relevant Information ↓ Agent Context例如 Agent B 真正需要的可能只有{ finding: SQL Injection, confidence: 0.91, evidence: ..., source: researcher }而不是整个Agent A 过去 50 轮聊天记录这其实就是Context Engineering。未来 Agent 系统真正重要的竞争力很大程度上就在这里。十三、上下文压缩Context Compaction当对话不断增长Message 1 Message 2 Message 3 ... Message 100不能无限发送给模型。所以需要Messages ↓ Summarizer ↓ Compressed Context例如def compact(messages): summary llm.generate( 将以下历史信息压缩成结构化摘要。 保留 1. 已确认事实 2. 未解决问题 3. 决策结果 4. 重要证据 ) return summary但这里有一个非常大的坑摘要本身也可能产生信息损失。所以生产环境不能只保存 summary。更合理的是Raw Event ↓ Summary ↓ Important Facts ↓ Vector Memory形成多层记忆。十四、Multi-Agent 最难的问题之一冲突假设Researcher 存在 SQL Injection Reviewer 不存在 SQL Injection到底听谁简单粗暴的方式最后一个 Agent 说了算这是非常危险的。成熟系统需要定义Conflict Resolution Policy。十五、冲突解决机制一优先级给 Agent 设置权重Security Expert 1.0 General Analyst 0.7 LLM Assistant 0.5最终score confidence * agent_weight例如Researcher: confidence 0.9 weight 1.0 Analyst: confidence 0.8 weight 0.7计算Researcher 0.90 Analyst 0.56最终选择 Researcher。十六、冲突解决机制二Evidence-Based Decision更可靠的方法不是比较谁更自信而是比较谁有证据例如{ claim: 存在 SQL Injection, evidence: [ parameter id directly enters SQL, no parameterized query, error message confirms SQL execution ], confidence: 0.94 }另一个 Agent{ claim: 不存在 SQL Injection, evidence: [], confidence: 0.73 }系统应该优先Evidence Confidence Agent Priority十七、冲突解决机制三裁判 Agent复杂系统可以增加一个Judge / Arbiter Agent架构Researcher ↓ ┌────┴────┐ ↓ ↓ Claim A Claim B \ / \ / ↓ ↓ Judge ↓ DecisionJudge 接收观点 证据 来源 置信度然后进行Evidence Evaluation Consistency Check Reasoning最终输出{ decision: accept, reason: ..., confidence: 0.92 }十八、不要忽略 Termination Condition这是很多 Multi-Agent Demo 最大的问题。如果 Agent A继续提问 BB继续让 A 验证最后A → B → A → B → A → B无限循环。所以必须设计Termination Policy例如MAX_ROUNDS 10 if round_count MAX_ROUNDS: terminate()除此之外还可以Final Answer Detected Confidence Threshold No Progress Repeated State Budget Exhausted Timeout十九、No Progress Detection这是一个非常实用的生产环境机制。假设连续三轮Round 7 结论风险存在 Round 8 结论风险存在 Round 9 结论风险存在但没有任何新增证据。说明系统已经进入Reasoning Loop。可以定义if similarity( result_current, result_previous ) 0.98: terminate()也就是说如果连续多个状态高度相似就停止继续调用模型。这类机制对降低 Token 成本非常有效。二十、Agent Communication 不应该只是自然语言Demo 里经常Agent A 我认为这个漏洞风险比较高…… Agent B 我觉得应该进一步分析……工程系统最好使用Structured Message。例如{ sender: researcher, receiver: reviewer, type: security_finding, payload: { severity: high, confidence: 0.92, evidence: [] } }这样做最大的好处Agent Communication 从自然语言变成了协议。二十一、为什么 Schema 比 Prompt 更重要如果输出只是这个漏洞风险比较高。程序很难处理。如果输出{ severity: high, confidence: 0.91, category: SQL Injection }Python 就可以直接if result[severity] high: create_ticket()所以生产级 Agent 系统应该逐渐从Prompt-driven转向Schema-driven也就是LLM ↓ Structured Output ↓ Validator ↓ Business Logic二十二、Agent State真正的核心数据结构如果让我自己设计一个 Multi-Agent Framework我会把 Agent 状态抽象成class AgentState: task_id: str agent_id: str status: str input_context: dict working_memory: list tool_results: list decisions: list output: dict error: str | None iteration: int状态变化CREATED ↓ RUNNING ↓ WAITING_TOOL ↓ TOOL_RESULT ↓ RUNNING ↓ COMPLETED如果失败RUNNING ↓ FAILED ↓ RETRY这其实已经非常接近Finite State Machine有限状态机。二十三、把 Agent 当成状态机而不是聊天机器人这是理解 Agent 架构非常重要的一次认知升级。普通聊天Input → LLM → OutputAgentInput ↓ State ↓ Decision ↓ Action ↓ Observation ↓ State Update ↓ Decision即Observe ↓ Think ↓ Act ↓ Observe ↓ Think ↓ ActMulti-Agent 则是Agent A State ↓ Communication ↓ Agent B State ↓ Communication ↓ Agent C State二十四、生产环境中的 Agent Loop可以抽象成while not state.finished: context build_context(state) decision llm_decide(context) action parse_action(decision) if action.type tool: result execute_tool(action) state.update(result) elif action.type delegate: result delegate(action) state.update(result) elif action.type finish: state.finished True state.output action.result注意LLM 不应该直接控制整个系统。LLM 只负责Decision而Tool Execution State Update Permission Check Retry Timeout Logging应该由确定性代码负责。二十五、这是 Agent 工程化最重要的一条原则我在做 Agent 系统时非常建议遵循让 AI 做判断让代码做约束。例如错误设计LLM ↓ 直接执行 Shell正确设计LLM ↓ Structured Action ↓ Policy Validator ↓ Permission Check ↓ Tool Executor ↓ Result例如模型只能产生{ action: scan, target: internal-service, timeout: 30 }然后程序检查if action[target] not in allowed_targets: raise PermissionError()这样才能把 Agent 从AI Demo变成可控的软件系统。二十六、Multi-Agent 为什么经常“越做越差”这是实际项目中非常常见的问题。很多人认为Agent 越多 智能越高实际上完全不一定。可能出现1 Agent → 80% 正确 3 Agents → 76% 8 Agents → 61%为什么因为Communication Cost Context Noise Error Propagation Coordination Overhead都会增加。二十七、Multi-Agent 的误差传播假设Agent A 正确率 95% Agent B 正确率 95% Agent C 正确率 95%如果 B 完全依赖 AC 完全依赖 BA → B → C整体正确率并不会简单等于 95%。理论上如果完全独立且每一步都必须正确0.95 × 0.95 × 0.95 ≈ 85.7%实际情况还会受到上下文污染 错误放大 错误确认影响。所以 Multi-Agent 不是简单地Agent 越多越强。真正应该追求的是最小化 Agent 数量同时最大化任务分解收益。二十八、什么时候应该使用 Multi-Agent我一般会看四个指标。第一任务是否天然可以拆分例如研究 编码 测试 审查如果高度独立就适合。第二是否存在明显专业角色例如Security Expert Database Expert Code Reviewer Product Analyst如果不同角色拥有明显不同的决策逻辑Multi-Agent 才有价值。第三是否需要并行例如同时分析 100 个文档Multi-Agent 可以提高吞吐。第四是否需要交叉验证例如Agent A 提出结论 Agent B 验证 Agent C 仲裁这类场景非常适合 Multi-Agent。二十九、一个企业级 Multi-Agent 架构应该长什么样如果让我从零设计一个生产级系统我不会直接从CrewAI AutoGen LangChain开始。我会先设计架构。┌───────────────┐ │ API Gateway │ └───────┬───────┘ ↓ ┌───────────────┐ │ Task Manager │ └───────┬───────┘ ↓ ┌───────────────┐ │ Orchestrator │ └───────┬───────┘ ↓ ┌──────────────┼──────────────┐ ↓ ↓ ↓ Researcher Coder Reviewer │ │ │ └──────────────┼──────────────┘ ↓ Context Manager ↓ Memory Layer ↓ Tool Gateway ↓ External Services外围再加Observability Tracing Logging Metrics Policy Engine Cost Controller Retry Manager这才是真正接近企业级架构。三十、ObservabilityAgent 系统必须可观测传统程序Request ↓ Function ↓ ResponseAgentRequest ↓ Agent ↓ LLM ↓ Tool ↓ Agent ↓ Agent ↓ LLM ↓ Tool ↓ Result如果没有 Trace出了问题几乎没办法定位。所以至少记录trace_id task_id agent_id model prompt_tokens completion_tokens latency tool tool_latency status error例如{ trace_id: T1001, agent: researcher, model: local-llm, latency: 2.31, tokens: 1832, status: success }三十一、Agent Cost ControllerMulti-Agent 最大的问题之一就是烧 Token。例如1 Task ↓ Planner ↓ Researcher × 3 ↓ Coder ↓ Reviewer × 2 ↓ Judge一次任务可能调用十几次甚至几十次模型。所以必须设计Budget例如class Budget: max_tokens 50000 max_llm_calls 20 max_cost 1.0一旦超过STOP而不是继续Agent → Agent → Agent三十二、未来 Agent 架构真正的竞争力是什么我认为不会是谁的 Prompt 写得更长而会逐渐变成Agent Architecture Context Engineering Memory Tooling Workflow Evaluation Observability Governance也就是说Prompt Engineer 的核心竞争力正在逐渐从“写提示词”转变成“设计智能系统”。三十三、从 Prompt Engineer 到 Agent Architect这个转变可以理解成Prompt Engineer ↓ Prompt Tool ↓ Single Agent ↓ Agent Workflow ↓ Multi-Agent ↓ Agent Architecture技能栈也会发生变化。以前Prompt LLM Few-shot RAG现在Prompt Python Workflow State Machine Memory Vector DB Tool Calling Structured Output Observability Distributed Systems最终Agent Architect 本质上正在成为一种新的软件架构岗位。三十四、如果让我从零实现一个 Multi-Agent Framework我不会一开始就做几十个模块。第一版只需要1. Agent 2. Message 3. State 4. Tool 5. Router 6. Memory 7. Orchestrator 8. Validator 9. Trace最核心的数据结构甚至可以非常简单class Message: def __init__( self, sender, receiver, content, message_typetext ): self.sender sender self.receiver receiver self.content content self.message_type message_type class Agent: def __init__( self, name, role, toolsNone ): self.name name self.role role self.tools tools or [] async def run(self, task): ... class Orchestrator: def __init__(self): self.agents {} def register(self, agent): self.agents[agent.name] agent async def dispatch(self, agent_name, task): agent self.agents[agent_name] return await agent.run(task)然后逐渐增加State ↓ Memory ↓ Tool Calling ↓ Parallel Execution ↓ DAG ↓ Retry ↓ Conflict Resolution ↓ Observability这比一开始直接上一个“大而全”的 Agent 框架更容易真正理解底层逻辑。三十五、真正值得研究的是框架背后的抽象所以如果你准备深入研究AutoGen / CrewAI / LangGraph 等框架不要停留在from xxx import Agent这种 API 层。建议直接画出源码调用链Agent ↓ Message ↓ Context ↓ LLM Client ↓ Tool Call ↓ State Update ↓ Router ↓ Next Agent ↓ Termination然后继续往下追Context 是怎么构建的 Message 是怎么路由的 Tool 是怎么注册的 Agent 状态在哪里保存 异常怎么重试 什么时候终止 多个 Agent 如何共享 Memory 模型输出如何转换成 Action当你能回答这些问题的时候你研究的已经不是“怎么使用 Agent 框架”而是“怎么设计 Agent Framework”。这两者是完全不同的能力层级。三十六、最后Multi-Agent 的终点不是“更多 Agent”这是我认为整个 Multi-Agent 架构里最值得记住的一句话真正优秀的 Agent 系统不是让更多 Agent 参与任务而是让每一个 Agent 在正确的时间、正确的上下文里完成正确的决策。所以未来真正值得研究的不是我能不能创建 100 个 Agent而是如何减少无效 Agent 如何降低 Context Noise 如何避免错误传播 如何让 Agent 可观测 如何让 Agent 可回滚 如何让 Agent 可验证 如何让 Agent 在预算内完成任务当你开始从这些问题出发的时候你其实已经从Prompt Engineer走向了Agent Architect。写在最后Multi-Agent 并不是简单地把几个大模型 API 串起来。它背后实际上融合了LLM 分布式系统 状态机 任务调度 消息通信 上下文工程 记忆系统 工具调用 权限控制 可观测性 异常恢复所以如果真正想把 Agent 做到生产环境建议不要只学习框架 API而是尝试自己实现一个最小 Multi-Agent Runtime。哪怕只有Agent Message State Router Tool Memory Orchestrator当这些东西真正跑起来之后再回头去看 AutoGen、CrewAI 等框架的源码会发现很多设计其实都能对应到自己已经理解的架构模块。这时候你才真正开始从“会调用 Agent”走向“会设计 Agent”。如果你对这部分底层实现感兴趣我整理了一份《多智能体框架底层源码分析思维导图》把 Agent、Message、Context、Memory、Tool Calling、Orchestrator、State Machine、Router、Termination 等核心模块串成了一条源码分析路线。对于准备深入研究 AutoGen、CrewAI 等 Multi-Agent 框架底层实现的开发者建议按照这条路线去拆源码而不是只停留在 API 使用层。你觉得未来 Multi-Agent 真正会取代传统 Workflow还是最终会变成 Workflow Agent 的混合架构欢迎在评论区聊聊你的看法。