企业官网建设流程全解析

1. 从"agency-agents"这个标题说起：一个多智能体协作框架的完整拆解

第一次看到"agency-agents"这个项目名的时候，我的直觉是：这大概率是一个围绕"代理（agent）"概念构建的协作系统，而且"agency"这个词放在前面，暗示了它不只是单个 agent 的能力展示，更强调"代理机构"式的组织化协作——也就是说，多个 agent 像一家公司里的不同角色一样，各司其职、互相配合，共同完成一个复杂任务。

这个判断在后续的拆解中基本得到了验证。简单来说，agency-agents 是一个多智能体（Multi-Agent）协作框架，它的核心目标是：把一个大而模糊的任务，拆解成若干个子任务，然后分配给不同角色定位的 agent 去执行，最后把结果汇总成一份完整的产出。它解决的问题很实际——单个大模型 agent 在面对复杂任务时容易"顾此失彼"，要么上下文太长导致注意力涣散，要么一个 agent 既要规划又要执行还要审核，角色混乱、质量不稳定。而 agency-agents 通过"分工"这个最朴素的工程思路，把复杂问题拆开处理。

这篇文章适合谁看？如果你正在做 AI 应用开发，尤其是想让多个 agent 协同完成写作、调研、代码生成、数据分析这类任务，那这篇内容会对你有直接帮助。如果你只是听说过"多智能体"这个词但没动手做过，我也会从最基础的设计思路讲起，尽量让你能跟着复现。全文我会围绕架构设计、角色定义、通信机制、任务编排、实操落地、问题排查这几个维度展开，把我在实际搭建类似系统时踩过的坑和总结的经验都放进去。

需要先说明一点：下面涉及的具体实现细节，有一部分是基于这类框架的常见工程实践做的合理补全，因为原始标题只给了一个名字，没有附带代码仓库或文档。但所有设计逻辑和取舍理由，我都会讲清楚"为什么这么做"，这样你即使换一套技术栈，也能把思路迁移过去。

2. 多智能体协作到底难在哪：先搞清楚核心痛点

2.1 单 agent 的天花板在哪里

很多人一开始做 AI 应用，都是从一个"万能 agent"起步的：给它一段系统提示词，告诉它"你是一个资深助手，能写作、能编程、能分析数据"，然后就把所有任务都丢给它。刚开始用着还行，但任务一复杂，问题就暴露了。

最典型的是角色冲突。你让同一个 agent 既当"创作者"又当"审核者"，它在生成内容时会倾向于自我肯定，审核环节形同虚设。这就像让一个人既当运动员又当裁判，很难做到客观。第二个问题是上下文污染：一个 agent 处理长任务时，前面步骤的中间结果会一直堆在上下文里，到后面它可能被无关信息干扰，输出质量断崖式下跌。第三个是难以并行：单个 agent 只能串行处理，一个环节卡住，整个流程就停了。

agency-agents 这类框架的价值，恰恰在于用"组织架构"的思路解决这些问题。它把"一个人干所有事"变成"一个团队分工干"，每个 agent 只关心自己那一小块，上下文干净、角色清晰、还能并行。

2.2 多 agent 协作的三个核心难题

不过，多 agent 不是简单地把任务分给几个模型调用就完事了。真正动手做，你会遇到三个绕不开的难题。

第一个是任务拆解的粒度问题。拆得太粗，每个 agent 还是面对一个模糊的大任务，等于没拆；拆得太细，agent 之间通信开销爆炸，协调成本比干活还高。我一般的经验是：每个子任务应该是一个 agent 在一次对话内能高质量完成的规模，大概对应"写一篇 800 字文章""分析一份 10 行数据""审查一段 50 行代码"这种量级。

第二个是 agent 之间的信息传递。A agent 的输出怎么给到 B agent？是传原始文本，还是传结构化数据？如果传原始文本，B 可能理解偏差；如果传结构化数据，又可能丢失上下文。实践中我倾向于混合模式：关键结论用结构化字段传递，背景信息用自然语言附带。

第三个是结果的一致性和冲突消解。多个 agent 可能给出矛盾的建议，谁来拍板？这就需要有一个"协调者"角色，或者设计一套投票/优先级机制。agency-agents 里通常会有 orchestrator（编排器）来承担这个职责。

理解了这三个难题，你再看任何多智能体框架，都会有一个清晰的评判标准：它怎么拆任务、怎么传信息、怎么消解冲突。下面我就按这个逻辑，把 agency-agents 的设计思路一层层拆开。

3. 架构设计拆解：agency-agents 是怎么组织起来的

3.1 三层结构：编排层、角色层、执行层

从工程角度看，agency-agents 这类框架基本都遵循一个三层结构，我把它画成文字版的架构说明：

编排层是整个系统的大脑。它拿到用户的总任务后，第一步是"规划"——把任务拆成有依赖关系的子任务列表。比如"帮我做一份行业调研报告"，编排层会拆成：检索资料 → 整理要点 → 撰写初稿 → 审核修订 → 格式化输出。然后它按依赖顺序调度各个角色 agent。

角色层是干活的主力。每个 agent 有自己的系统提示词、能力边界和输出格式约定。关键在于，每个 agent 的提示词要写得足够"窄"，只聚焦自己那一件事。我见过很多失败的案例，就是 agent 提示词写得太宽泛，结果它总想越界干别人的活。

执行层是基础设施，负责真正调用模型接口、执行工具函数、存取记忆。这一层通常和具体业务无关，是可以复用的底座。

3.2 为什么用"角色"而不是"函数"来划分

这里有个设计选择值得展开说：为什么 agency-agents 用"角色（agent）"来划分工作，而不是像传统程序那样用"函数"来划分？

核心区别在于灵活性和容错性。函数是确定性的，输入 A 必然输出 B；而 agent 是概率性的，同样的输入可能给出不同但都合理的输出。在写作、调研、创意这类任务里，这种"不确定性"反而是优势——你希望 agent 能根据实际情况灵活调整，而不是死板地执行。

但代价是可控性下降。所以好的框架会在角色层之上加一层"约束"：给每个 agent 明确的输出格式要求（比如必须返回 JSON）、明确的边界（不许做 X）、明确的验收标准。这样既保留了灵活性，又保证了可控性。

3.3 通信机制：消息总线还是直接调用

agent 之间怎么通信，是架构设计里另一个关键决策。常见的有两种模式：

• 直接调用：A agent 执行完，直接把结果作为参数传给 B agent。简单直接，但耦合度高，A 必须知道 B 的存在。
• 消息总线：所有 agent 把结果发到一个共享的消息队列，谁需要谁去取。解耦好，但调试复杂。

agency-agents 这类框架，我观察到多数采用混合方案：编排层持有全局的任务图，agent 之间不直接通信，而是通过编排层中转。这样编排层可以记录每一步的输入输出，方便调试和回溯。这个设计我觉得很务实——多 agent 系统最怕的就是"黑盒"，出了问题不知道是哪一步坏的，有了编排层做中转，每一步都可观测。

4. 角色定义与提示词工程：让每个 agent 各司其职

4.1 一个合格 agent 角色的四个要素

在 agency-agents 里定义一个 agent，不是随便写句"你是一个助手"就完事。我总结下来，一个能稳定工作的 agent 角色，至少要包含四个要素：

1. 身份定位：它是谁，代表什么专业视角。比如"你是一位有十年经验的财经编辑"。
2. 能力边界：它能做什么、不能做什么。明确写"你只负责 X，不要涉及 Y"。
3. 输出格式：它必须按什么格式返回结果。这是保证下游 agent 能接住的关键。
4. 质量标准：什么样的输出算合格。比如"每个论点必须有数据支撑"。

这四要素缺一不可。我踩过的最大的坑，就是早期只写了身份定位，没写输出格式，结果 agent 返回一大段自然语言，下游 agent 解析起来全靠猜，稳定性极差。

4.2 提示词里的"防越界"技巧

多 agent 系统里，agent 越界是最常见的故障。比如你让"检索 agent"去查资料，它查着查着开始自己写结论了；你让"审核 agent"挑毛病，它挑着挑着直接帮你重写了。

防越界的核心技巧是在提示词里显式禁止，而且要具体。不要写"专注于你的任务"这种空话，要写"你只输出检索到的原始资料和来源链接，不要做任何总结、评价或改写"。越具体，agent 越不容易跑偏。

另一个技巧是用输出格式反向约束行为。如果你要求 agent 必须返回一个固定结构的 JSON，它就没法自由发挥去写大段文字。格式本身就是一种约束。

4.3 角色之间的依赖怎么表达

agency-agents 里，角色不是孤立的，它们之间有依赖关系。这个依赖关系通常由编排层用一张"任务图"来表达。举个具体的例子，做一份调研报告的任务图可能是这样的：

researcher → analyst → writer → reviewer → formatter

箭头表示数据流向。researcher 的输出给 analyst，analyst 的给 writer，以此类推。但实际项目里往往更复杂，会有并行和汇聚：

researcher_a ─┐ ├→ analyst → writer → reviewer researcher_b ─┘

两个检索 agent 并行工作，结果汇聚给一个分析 agent。这种图结构用有向无环图（DAG）来描述最合适，编排层按拓扑排序依次调度即可。

提示：设计任务图时，尽量让每个节点的输入来源单一。如果一个 agent 要同时接收三四个上游的输出，它的提示词会变得极其复杂，出错概率大增。宁可多加一个"汇总 agent"做中转。

5. 任务编排与执行流程：从输入到产出的完整链路

5.1 编排器的核心逻辑

编排器（Orchestrator）是整个流程的指挥官。它的工作可以拆成四步：解析任务 → 生成计划 → 调度执行 → 汇总结果。

第一步解析任务，是把用户的自然语言输入转成结构化的任务描述。这一步通常也用一个 LLM 来做，让它输出"任务类型、目标、约束条件、期望产出"这几个字段。

第二步生成计划，就是前面说的拆解成任务图。这里有个经验：计划不要一次生成到底，而是分层生成。先定大阶段（检索、分析、写作、审核），再对每个阶段细化子步骤。一次性生成太细的计划，往往因为缺乏中间信息而不准确。

第三步调度执行，按任务图的依赖关系，能并行的并行，有依赖的串行。第四步汇总，把所有 agent 的输出整合成最终交付物。

5.2 一个完整的执行时序

我把一次典型的 agency-agents 执行过程按时间顺序列出来，方便你对照理解：

1. 用户输入总任务，编排器接收。
2. 编排器调用规划能力，生成任务图（含各节点角色、依赖、输入输出约定）。
3. 编排器按拓扑顺序，把无依赖的节点（如多个检索任务）并行派发给对应 agent。
4. 每个 agent 执行时，编排器把它的输入（上游输出 + 自身角色提示词）组装好，调用模型。
5. agent 返回结果，编排器校验格式，存入共享记忆。
6. 依赖满足后，调度下一批节点，重复 4-5。
7. 所有节点完成，编排器调用"汇总 agent"或自身逻辑，整合最终产出。
8. 返回给用户，同时保留完整执行日志。

这个流程里，第 5 步的格式校验非常关键。如果 agent 返回的格式不对，编排器应该能识别并触发重试，而不是把错误数据传给下游。我一般会设置最多 2-3 次重试，超过就标记该节点失败，走降级逻辑。

5.3 并行执行的收益与代价

并行是多 agent 系统的一大卖点，但也不是无脑并行。收益很明显：多个独立子任务同时跑，总耗时从"求和"变成"取最大值"。比如三个检索任务各需 10 秒，串行 30 秒，并行只要 10 秒。

但代价也有：并发调用模型接口会触发限流，尤其是用同一套 API key 的时候。我的做法是给并发数设一个上限（比如 5），超出的排队。另外，并行任务的结果汇总需要额外处理，如果几个 agent 的输出有冲突，还得有个消解机制。

注意：并行度不是越高越好。实测下来，并发数超过 8 之后，限流和超时的概率明显上升，整体吞吐反而下降。找到你所用接口的"甜点区"很重要。

6. 实操落地：从零搭一个最小可用的多 agent 系统

6.1 环境与依赖准备

要复现一个 agency-agents 风格的系统，你需要的核心依赖其实不多。我用 Python 举例，主要就几样：

pip install openai pydantic tenacity

• openai（或对应的模型 SDK）：负责调用大模型。
• pydantic：负责定义和校验 agent 的输入输出结构，这是保证稳定性的关键。
• tenacity：负责重试逻辑，处理接口偶发失败。

如果你要做更复杂的编排，可以引入langgraph或自己写一个简单的 DAG 调度器。但我建议第一版不要上重框架，先用最朴素的代码把流程跑通，理解每一步在干什么，再考虑引入框架。

6.2 定义 agent 的数据结构

先用 pydantic 把 agent 的输入输出定死，这是整个系统稳定的地基：

from pydantic import BaseModel from typing import List class AgentInput(BaseModel): task: str context: str = "" upstream_results: List[str] = [] class AgentOutput(BaseModel): content: str sources: List[str] = [] confidence: float = 1.0

这样每个 agent 必须返回符合AgentOutput结构的数据，编排器拿到后可以直接用，不用猜格式。confidence字段是我强烈建议加的，让 agent 自己评估一下把握程度，低置信度的结果可以触发人工复核或重试。

6.3 写一个通用的 agent 执行函数

不用给每个角色写一个函数，写一个通用的执行器，把角色提示词作为参数传进去就行：

def run_agent(role_prompt: str, agent_input: AgentInput) -> AgentOutput: messages = [ {"role": "system", "content": role_prompt}, {"role": "user", "content": build_user_prompt(agent_input)} ] response = call_llm(messages) return AgentOutput.model_validate_json(response)

build_user_prompt负责把任务、上下文、上游结果拼成一段清晰的用户消息。这里有个细节：上游结果要标注来源，比如"以下是检索 agent 提供的资料：..."，让当前 agent 知道这段信息的性质。

6.4 编排器的简化实现

编排器第一版可以很简单，用一个列表表示任务序列，逐个执行：

def orchestrate(task: str): plan = generate_plan(task) # 返回 [(role, prompt), ...] results = [] for role, prompt in plan: agent_input = AgentInput( task=task, upstream_results=[r.content for r in results] ) output = run_agent(prompt, agent_input) results.append(output) return merge_results(results)

这个版本不支持并行，也不支持复杂依赖，但足够让你跑通"检索→分析→写作→审核"这条链路。跑通之后，再把串行改成 DAG 调度，把并行加进去。

6.5 参数选择与成本估算

多 agent 系统比单 agent 贵，这是必然的，因为一次任务要调用多次模型。我一般这样估算成本：假设一次任务经过 5 个 agent，每个 agent 平均消耗 2000 token 输入、1000 token 输出，那总消耗就是 10000 输入 + 5000 输出。按主流模型的价格算，一次任务成本大概在几分钱到几毛钱之间。

控制成本的关键是控制上下文长度。上游结果不要全量传给下游，只传关键结论。我通常会让每个 agent 在输出里额外给一个"摘要"字段，下游默认只读摘要，需要细节时再读全文。这一招能把 token 消耗降下来一大半。

7. 常见问题与排查技巧实录

7.1 问题速查表

7.2 三个我踩过的坑

第一个坑：agent 提示词写得太"聪明"。早期我总想让每个 agent 都"全面考虑"，结果它们互相抢活干，输出重复又矛盾。后来我把提示词改得极其"笨"——每个 agent 只干一件事，多余的一律不做。系统反而稳定了。这印证了一个道理：多 agent 系统的智能来自"协作"，而不是单个 agent 的"全能"。

第二个坑：忽略中间结果的校验。有一次上游 agent 返回了一个空结果，下游 agent 基于空结果硬编，最后产出一篇看似完整实则空洞的报告。从那以后，我在每个节点后都加了校验：内容为空、长度异常、置信度过低，都会触发重试或告警。

第三个坑：没有保留执行日志。多 agent 系统出问题时，最难的是定位是哪一步坏的。后来我强制要求编排器记录每一步的完整输入输出，存成结构化日志。有了日志，排查时间从半小时缩短到几分钟。

7.3 提升稳定性的几个实用技巧

• 给每个 agent 设超时：单个 agent 卡住不能拖垮整个流程，超时就跳过或降级。
• 关键节点双跑：对质量要求高的节点（如最终审核），可以跑两次取更优结果，成本换质量。
• 用温度参数区分角色：检索、审核类 agent 用低温度（0.1-0.3）保证稳定，创意写作类用高温度（0.7-0.9）保证多样性。
• 定期回归测试：准备一批标准任务，每次改动后跑一遍，看输出质量有没有退化。

提示：多 agent 系统的调试成本远高于单 agent，所以从第一天起就要把"可观测性"做进去。日志、指标、追踪，一个都别省。

8. 这套框架还能怎么扩展

agency-agents 的思路其实不局限于"写作+审核"这类文本任务。我最近在尝试的几个扩展方向，也一并分享出来。

一个是接入外部工具。给检索 agent 接上真实的搜索接口或数据库查询，它就不只是"凭记忆回答"，而是能拿到实时数据。这一步的关键是给工具调用设计好错误处理，接口失败时 agent 要能优雅降级。

另一个是引入人类反馈环节。在关键节点（比如最终审核前）插入一个人工确认步骤，让人类决定是否继续。这在质量要求高的场景里很实用，相当于给自动化流程加了个"安全阀"。

还有一个是让 agent 具备记忆。把历史任务的结论存进向量库，新任务开始时先检索相关历史，避免重复劳动。这个扩展能让系统越用越"聪明"，但要注意记忆的时效性和准确性，过期的记忆反而会误导 agent。

我个人在实际操作中的体会是：多 agent 系统的价值不在于"用了多少个 agent"，而在于"分工是否合理、协作是否顺畅"。一个设计良好的三 agent 系统，往往比一个混乱的十 agent 系统产出更好。所以别急着堆数量，先把每个角色的边界和接口定义清楚，让信息在 agent 之间干净地流动，这才是这类框架真正的功力所在。