企业官网建设流程全解析

第一次听到 “agency-agents” 这个词，我满脑子都是问号——这到底是在说某个“代理商系统”，还是单纯把 agent 复数一下？直到我把一个又长又复杂的 AI 任务拆给了由 7 个 Agent 组成的小团队，看着它们像流水线一样各干各的，最后自动拼出一份完整报告，我才意识到：这里的 agency，讲的并不是传统意义上的“代理公司”，而是一种把多个 AI Agent 组织成一个可调度、可协作、可治理的“智能体团队”的架构设计。

这几年大模型的能力越来越强，但单靠一个 Agent 打天下，很快会撞上上下文窗口、角色冲突、工具调度和错误率的天花板。agency-agents 要解决的，正是“如何把个人英雄主义式的单 Agent，改造成工业化协作的智能体班组”。这篇文章我会用整套实操视角，从架构拆解、协作模式、关键组件，到代码原型、性能调优和避坑经验，一步步讲清楚它到底是什么、能做什么、适合谁参考。

如果你正在折腾多 Agent 系统，或者手上有一个复杂任务想把 AI 自动化，又不想一上来就上重框架，那这篇内容应该能给你一份可以直接落地的思路。

1. 为什么需要 “agency-agents” 这种设计

1.1 单个 Agent 的瓶颈在哪里

很多人最开始接触大模型应用，都是从一个 Agent 开始的：一个 system prompt，加上几个工具，再配一个会话窗口，就能处理很多简单任务。但我在实际项目里很快发现，这种“万能助手”模式有几个躲不过去的坎。

第一是上下文窗口被快速塞满。一个 Agent 既要做信息检索，又要做逻辑推理，还要写最终交付物，所有中间过程都会堆在同一个上下文里。任务一长，前面的重要内容可能被挤掉，模型就开始“失忆”。第二是角色冲突。同一个 Agent 既要扮演严谨的分析师，又要扮演有创造力的写作者，还要扮演挑刺的质检员，这种多角色切换在长文本里一定会互相污染。第三是工具调用越来越乱。多个工具挂在同一个 Agent 身上，模型容易选错工具、传错参数，或者在几个工具之间来回循环。

我自己踩过最深的坑，是让一个单 Agent 同时完成“收集资料 → 整理要点 → 写报告 → 检查格式”整个链路。结果它在前两步表现还行，到了写报告阶段，开始把未经验证的原始信息直接当成结论输出，错得离谱。问题不在模型本身，而在于一个 Agent 承担了太多不该同时承担的责任。

1.2 从“万能助手”到“代理公司”

agency-agents 的思路，就是把一个庞大、复杂的“万能助手”，拆分成一组各司其职的小型 Agent，再让它们像一家小型“代理公司”一样配合运转。这家“公司”里，有负责拆解任务的“项目经理”，有负责收集情报的“研究员”，有负责落笔写稿的“文案”，还有负责纠错的“质检员”。

每个 Agent 只干一件本职的事，Prompt 可以做得非常细、非常聚焦。这样一来，模型不需要在不同角色之间反复横跳，上下文里只有和当前任务相关的内容。举一个生活化的类比：一家公司不会让一个人既当会计又当销售还当售后，而是让每个人只守好自己的岗位，再通过流程把大家串起来。多 Agent 架构也是同样的逻辑。

从我实践中得到的经验来说，这种设计还有一个隐藏的好处：单个 Agent 出错时，影响范围被隔离了。如果“研究员”阶段抓取的信息有问题，“写手”和“质检员”更容易发现异样；就算没发现，定位问题的时候也能直接找到是哪一环出了错，而不是面对一大团黑盒输出无从下手。

1.3 这个架构适合解决哪类问题

并不是所有任务都适合上多 Agent。把一句“帮我把这段文字润色”拆给 5 个 Agent，纯粹是浪费时间和 Token。我在实际项目里总结出三个适合 agency-agents 的特征。

任务有明显的阶段链路。比如“调研 → 分析 → 输出 → 审核”，每个阶段有相对独立的输入输出。任务需要多种专业能力协作。比如既要写代码，又要写文档，还要做测试。任务有较高的准确率要求，需要有多轮检查和纠偏机制。

如果你手头的任务满足其中两条以上，就值得考虑用多 Agent 架构来承接。我第一次在一个语义理解项目中应用这个模式时，光是在数据清洗和实体识别两个 Agent 之间增加了一道“交叉验证”环节，最终准确率就提升了近 3 个百分点。这种收益，在单 Agent 架构里几乎不可能拿到。

2. 核心协作模式与关键组件拆解

2.1 几种主流协作拓扑的对比

多 Agent 系统看起来都是“一群 Agent 干活”，但内部协作的组织方式差异巨大。我梳理了最常见的四种拓扑：中心化编排模式、流水线串行模式、自由讨论模式、分层委托模式。

我自己的习惯是：大多数自动化任务用“中心化编排 + 流水线执行”的混合结构，因为它在可控性和质量之间最平衡。先让编排器把目标拆成步骤，再按依赖关系把它们分配给下游 Agent，最后统一回收结果。自由讨论模式我一般只在头脑风暴类场景里用，比如让两个 Agent 就同一份方案互提意见，迭代三轮后取最终稿。

2.2 角色配置与任务卡设计

角色配置是 agency-agents 里最基础也是最容易被低估的环节。我不建议只写“你是一个研究员，负责搜集资料”这种一句话 Prompt，那和单 Agent 的 system prompt 没有本质区别。真正有效的角色配置，需要包含三块内容：职责边界、输出格式、协作规则。

职责边界要写清楚“这个角色不做什么”。比如研究员角色的 Prompt 里要有“不要直接撰写结论，只输出事实要点和来源列表，把写作交给写手”。这能显著减少 Agent 越权行为。输出格式尽量结构化成 JSON 或 Markdown，方便下游 Agent 直接解析。协作规则要明确它应该从哪个上游接收数据、把结果交给谁。

我把这种结构化的角色配置称为“任务卡”。一个任务卡就是一份小型的上下文契约。团队里每个 Agent 都只认自己的任务卡，不关心上下游在做什么细节，只需要知道自己要接收什么、输出什么。这套机制让整个系统的逻辑变得非常干净。

2.3 状态流转与消息协议

多 Agent 协作最隐蔽的坑，是消息格式不统一。比如研究员输出的是自然语言段落，写手期待的是结构化要点，两边一旦对接不上，整个流水线就垮了。所以在设计阶段，一定要先定义清楚消息协议。

我的做法是定义统一的“任务对象”，包含以下字段：任务 ID、父任务 ID、发布者、接收者、任务状态、输入上下文、输出结果、错误信息。任何 Agent 之间传递的信息都包装在这个结构里，不允许直接传裸字符串。这样一来，编排器可以很轻松地追踪每个任务的前后依赖关系，排查问题时也能顺着任务 ID 一路查下去。

状态流转我也建议显式定义：pending（等待中）、running（执行中）、succeeded（成功）、failed（失败）、retrying（重试中）。每次状态变更都要写一条状态日志。有一次我排查一个 Agent 一直卡住的问题，发现它把结果返回到“某个共享变量”里，但是编排器读取的却是“消息队列”里的值，两边根本没接上。从那以后，我强制所有状态变更都走统一接口，不再允许直接改共享变量。

3. 从零搭建一套可运行的 agency-agents 原型

3.1 定义 Agent 基类与运行入口

理论讲再多，不如直接跑一个原型。我以 Python 为例，展示我常用的一套极简实现框架。这套框架不需要依赖任何重型的 Agent 编排库，核心也就 200 行代码左右，但足够把真实的协作链路跑通。

我通常会先定义一个 AgentBase 基类，让它负责统一的大模型调用、工具注册、上下文拼装和日志输出。每个具体角色只需要继承这个基类，然后实现自己的工作逻辑。

class AgentBase: def __init__(self, name, system_prompt, tools=None): self.name = name self.system_prompt = system_prompt self.tools = {t.name: t for t in (tools or [])} def run(self, task, context): messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": context} ] # 这里调用你实际使用的大模型接口，并支持工具调用 response = call_llm(messages, tools=self.tools) self.log_response(self.name, response) return response

这个基类的关键点在于：每个 Agent 的 system_prompt 是独立且聚焦的，不允许在运行时被其他内容覆盖。这个方法看起来很朴素，但其实已经解决了上下文污染的大问题。

3.2 任务分解与派单逻辑

有了基类，下一步是写一个最简编排器。编排器的核心任务是两个：任务规划和任务派发。任务规划是把用户输入的大目标拆成若干可执行的小任务，并标明每个小任务之间的依赖关系。任务派发是根据依赖关系，把任务按顺序或并行分配给对应 Agent。

我最开始写编排器时，试图让大模型一步到位地输出一个完整 JSON 计划，但实际效果很不稳定。后来改成两步走：先让“项目经理 Agent”输出一个粗粒度的阶段列表，再让每个执行 Agent 自己输出更细的拆解步骤。这样做看似多了一次调用，但整体稳定性明显提升。

class Orchestrator: def __init__(self, registry): self.registry = registry self.memory = {} def dispatch(self, task): stage = task.stage agent = self.registry.get(stage.owner) context = self.build_context(task) for attempt in range(3): try: result = agent.run(task, context) self.memory[task.id] = result return result except RetryableError as e: self.log_retry(stage, attempt, e) raise RuntimeError(f"stage {stage} failed after 3 attempts")

build_context 函数只收集该任务真正需要的上下文，不把全局状态全部塞进去。这一点非常重要，它能让每个 Agent 只看到自己的“任务窗口”，避免无关信息干扰判断。

3.3 定义几个具体的角色 Agent

为了让原型更直观，我定义了五个常用角色：项目经理、研究员、写手、质检员、汇总专家。每个角色都有自己的专有 Prompt 和任务卡。

项目经理负责把用户的一句话目标拆解成结构化阶段。它的输出会成为编排器的执行蓝图。研究员负责信息检索和事实收集，它需要调用外部搜索工具，并把结果整理成带来源的要点列表。写手负责根据研究员的要点撰写初稿，只负责“写”，不需要自己去找资料。质检员负责对照原始需求检查初稿，列出逻辑错误、事实疑点和格式问题。汇总专家在质检通过后，负责把所有产物整合成最终交付文档。

RESEARCHER_PROMPT = """ 你是团队中的研究员，职责是收集与任务相关的资料，并输出结构化的要点列表。 你的输出必须包含 sources 字段，每个要点必须有对应的参考来源。 你不负责撰写最终结论，只负责提供事实依据。 """ WRITER_PROMPT = """ 你是团队中的写手，职责是根据研究员提供的要点列表撰写初稿。 你的输出必须是一篇结构完整、语言流畅的文档。 你不负责检查事实准确性，也不负责寻找新资料。 """ CRITIC_PROMPT = """ 你是团队中的质检员，职责是检查写手稿件中的逻辑问题和事实疑点。 你只输出问题清单，不直接修改稿件。每个问题必须附带严重级别和修改建议。 """

这套角色划分看起来很简单，但跑过一次真实任务后你就会发现：让“写手”不带事实核查任务，它的输出质量反而更高，因为它的注意力完全集中在表达和组织上。

3.4 用消息队列打通真实协作链路

角色定义好后，还有最后一步：把它们的输出真正串起来。我建议在原型阶段就引入一个简单的消息队列机制，不要用全局变量传递结果。最简单的办法是用 Python 的队列结构，或者直接在一张任务表里维护每个 Agent 的状态。

我常用的方式是：编排器依次拿到每个阶段的结果，写进一个共享的“任务结果表”。后续阶段从表里读取自己需要的数据，构造新任务，再交给下一个 Agent。整个过程看起来就像流水线，每个环节都有明确的上游和下游。

下面是一个最小执行主循环：

def run_pipeline(user_request): plan = orchestrator.plan(user_request) results = [] for stage in plan: if stage.deps: stage.context = collect_results(results, stage.deps) stage_result = orchestrator.dispatch(stage) results.append(stage_result) return compose_final_output(results)

跑通这一步之后，agency-agents 的核心骨架就算立住了。后续要加人机审核节点、加记忆模块、加并行执行，都是在这个骨架上做扩展。

4. 性能调优与常见问题排查实录

4.1 上下文污染：最隐蔽的拦路虎

我把上下文污染列为多 Agent 系统第一坑，因为它真的很隐蔽。症状表现为：某个 Agent 的输出莫名其妙变差，但你重试几次又时好时坏；或者下游 Agent 把上游某段无关内容当成了主要任务来执行。

我排查这类问题的方法很直接：给每次 Agent 调用记录“上下文摘要日志”，把送入和送出的消息都存下来。一旦发现问题，就回溯当时这个 Agent 看到的上下文到底是什么。实测下来，九成问题都是因为把全局状态一股脑塞给了所有 Agent。

解决办法也很清晰：每个任务定义明确的“上下文白名单”，除了任务卡、上游必要输出和少量全局常量之外，其他内容一概不传。宁可多传一次必要数据，也不要为了省事而把所有内容放进全局 Context。

4.2 死循环与任务重试风暴

多 Agent 系统另一个容易翻车的地方是循环。比如“质检员”发现一堆问题，把任务退回给“写手”，“写手”修改后再交回来，“质检员”又发现新的问题，于是再次退回，两个 Agent 形成无限循环。

我一开始用简单的“最大重试次数”来限制，比如质检退回最多 3 次，超过就直接跳过。但这治标不治本。后来我在编排器里加了一个“变更差异检测”：如果某次修改产出相比上次没有明显差异，就直接放行进入下一阶段。这个小改动让系统的循环率大幅下降。

还有一种是工具调用死循环。某个 Agent 在调用搜索工具后，拿到结果又继续调用搜索，每次换一个关键词，永远不进入总结环节。我通常会给工具调用设置次数配额，并在 Prompt 里明确写“当已有足够信息时，立即进入输出阶段”。

4.3 Token 预算与成本控制

多 Agent 架构相比单 Agent 调用，Token 消耗会有明显上升。尤其当你加上了“质检”和“重试”，成本可能翻三四倍。所以预算控制是必须提前做的。

我的经验是：在编排器层面设立 Token 池。每个阶段分配一个额度，比如研究员最多用 X 千 Token，写手最多用 Y 千 Token，超过额度强制截断输出。这样即使某个环节失控，整体预算也封在可控范围内。还有一个实用的技巧：在每个 Agent 接收上下文前做一次压缩，去掉重复信息、合并相似要点。上下文瘦身 30%，成本往往能降一大截，而质量损失很小。

4.4 可观测性：给每个 Agent 挂上计时器和日志

调试多 Agent 系统，最大的痛苦是不确定问题出在哪个环节。我强烈建议在搭建第一天就做好三件事：给每个 Agent 的每次调用记录开始时间、结束时间、消耗 Token 数、状态码；所有跨 Agent 消息都打印结构化日志，包含任务 ID 和上下游关系；把关键节点的输出摘要存到一个独立的可检索文件里，方便回溯。

有一次系统响应特别慢，我通过日志发现是“汇总专家”阶段里，某个循环查询工具被调用了二十多次，每次都要等外部接口返回。定位到具体 Agent 和具体工具之后，半小时就修复了。如果没有日志，这种问题可能要花一整天去猜。

5. 更进一步：让架构真正进入生产环境的经验

5.1 加一层共享记忆模块

原型跑通后，再往深处走，你会发现仅仅把结果存在编排器的内存表里并不够。真实的业务往往需要跨会话、跨任务复用经验和知识。这时候我会给系统加一个共享记忆模块，本质上就是外置的向量数据库或普通文档库，负责存几类内容：历史任务的关键结论、团队 Agent 的偏好配置、常见问题的处理方案。

研究员发现某个信息源质量很差，就可以把这条经验写进记忆模块，之后所有检索任务都会对这个信息源降权。质检员发现某类错误频繁出现，也可以把案例存入记忆，后续检查时会更加留意。这个设计让整个系统具备了简单的“团队学习能力”。

5.2 引入人机协同的审批节点

并不是所有环节都适合让 Agent 全自动跑完。在业务价值高、出错了代价大的环节，我会在流程里加入一个“人机审批节点”。比如质检员对比报告初稿和原始需求，返回“重大修改建议”时，系统不直接把建议推给写手，而是先弹给人工确认。

我在一个自动化报告生成的系统中就是这样做的。前几步全自动跑，但最终发布前会推送给人工审阅人，审阅人只需确认或小幅修改。这样的好处是，既享受了多 Agent 自动化带来的效率提升，又把风险可控地挡在最终交付前。

5.3 灰度验证与回归测试

多 Agent 系统的 Prompt 改动，比想象中更容易引发连锁反应。你可能只是改了一个写手的措辞，结果研究员和质检员的配合节奏全变了。所以不要把 Prompt 当作文档随便改，要像改代码一样管理。

我会在系统中内置一组回归测试用例。每次改动任何 Prompt 或编排逻辑，都会先用这组用例全量跑一遍，对比输出质量指标。只有质量没有下降才允许推上线。这个习惯帮我把多 Agent 系统的稳定性提升了非常多，强烈建议从一开始就做起来。认真讲，这套机制的建立时间不会超过小半天，但它能帮你守住长期质量底线。

还有个容易被忽略的细节：给核心 Prompt 加上版本号，并在每次输出中带上版本标签。哪份报告出自哪个版本，瞬间可查。排查线上问题时非常有用，因为很多问题换一次 Prompt 就时有时无，没有版本追踪根本定位不准。

写在最后

我在实际项目里把一片混乱的“多个 Agent 各跑各的”，真正变成了一套“agency-agents”式的协作团队之后，最大的感受是：复杂度并没有消失，而是被转移到了编排层。只要编排器清楚、任务卡明确、消息协议统一，多 Agent 的复杂度反而变得有序、可控、可扩展。

最后再分享一个小技巧：如果不知道自己的任务该拆成几个 Agent，先从“三个角色”起步——一个执行者、一个质检员、一个组织者。跑通之后再按需加人。不要一上来就铺十个 Agent，否则光是对齐它们之间的输入输出，就足以耗尽你的耐心。

希望这套经验能帮你少走一些弯路。多 Agent 架构的门槛没有想象中高，关键是想清楚分工、协议和编排这三件事。祝你搭出来的智能体团队，第一个版本就能跑得顺、用得稳。