企业官网建设流程全解析

如果你还在研究“怎么写一个更好的 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( role="Security Researcher", goal="分析目标系统的安全风险", tools=[ search_tool, document_tool ], output_schema=SecurityFinding )

注意这里真正重要的不是：

role="Security 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 Executor

2. 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_iterations=5 )

这其实已经非常接近传统软件工程里的：

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 Graph（DAG）

例如：

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 最容易爆炸的地方

单 Agent：

User ↓ Context ↓ LLM

非常简单。

Multi-Agent：

Agent 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 State

Global 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 ↓ Decision

Judge 接收：

观点 证据 来源 置信度

然后进行：

Evidence Evaluation + Consistency Check + Reasoning

最终输出：

{ "decision": "accept", "reason": "...", "confidence": 0.92 }

十八、不要忽略 Termination Condition

这是很多 Multi-Agent Demo 最大的问题。

如果 Agent A：

继续提问 B

B：

继续让 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 → Output

Agent：

Input ↓ State ↓ Decision ↓ Action ↓ Observation ↓ State Update ↓ Decision

即：

Observe ↓ Think ↓ Act ↓ Observe ↓ Think ↓ Act

Multi-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 完全依赖 A，C 完全依赖 B：

A → 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

这才是真正接近企业级架构。

三十、Observability：Agent 系统必须可观测

传统程序：

Request ↓ Function ↓ Response

Agent：

Request ↓ 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 Controller

Multi-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_type="text" ): self.sender = sender self.receiver = receiver self.content = content self.message_type = message_type class Agent: def __init__( self, name, role, tools=None ): 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 的混合架构？欢迎在评论区聊聊你的看法。