企业官网建设流程全解析

1. 从"agency-agents"这个名字说起：它到底在解决什么问题

第一次看到agency-agents这个命名，我的直觉是：这大概率是一个围绕"代理"和"智能体"做文章的项目，而且agency这个词放在前面，说明它强调的不是单个 agent 的能力，而是"代理机构"式的组织化协作。换句话说，它想解决的核心问题不是"怎么让一个 AI 干活"，而是"怎么让一群 AI 像一家公司一样分工干活"。

这个判断不是凭空来的。过去两年我陆续接触过不少多智能体（Multi-Agent）相关的项目，绝大多数都卡在同一个地方：单个 agent 跑 demo 很惊艳，一旦要它处理稍微复杂一点的任务，比如"调研一个行业并输出一份带数据的报告"，就会开始胡言乱语、上下文爆炸、任务半途而废。原因很简单——一个 agent 既要规划、又要执行、还要自我检查，角色冲突太严重，就像让一个人同时当老板、当员工、还当质检员，最后什么都做不好。

agency-agents这类项目的价值，恰恰在于它把"一家代理机构"的组织结构搬进了代码里。它通常包含几个关键角色：负责拆解需求的协调者、负责具体执行的专员、负责审核结果的质检方，以及负责在多个方案之间做取舍的决策层。每个角色是一个独立的 agent，各自有明确的职责边界、独立的上下文窗口和专属的工具集。这种设计思路，本质上是把"组织管理"的智慧迁移到了 AI 系统里。

适合读这篇内容的人有三类：一是正在做多智能体编排、被"任务跑不完"折磨的开发者；二是想理解 agent 协作底层逻辑、但被各种框架名词绕晕的技术爱好者；三是需要把 AI 能力落地到实际业务流程、却不知道从哪下手的团队负责人。我会尽量把原理讲透，同时给出可以直接抄的实操路径，不管你是刚入门还是已经踩过几个坑，都能拿到点东西。

需要先说明一点：由于原始项目正文和关键词都是空的，下面涉及的具体实现细节、目录结构、参数配置，都是基于我在同类多智能体项目中的常见实践做的合理补全，目的是让你能真正跑起来、理解透，而不是停留在概念层面。

2. 拆开"代理机构"的黑盒：agency-agents 的协作骨架长什么样

2.1 为什么是"机构"而不是"团队"

很多人会把多智能体系统叫成"agent team"，但agency-agents用的是agency，这个词的差别很关键。团队（team）强调的是成员之间的平等协作，而机构（agency）强调的是委托-代理关系：客户把需求委托给机构，机构内部再层层分解、分派、执行、验收。这个语义差异直接决定了系统的架构设计。

在机构模型里，最顶层不是某个"全能 agent"，而是一个任务受理层。它只做三件事：接收原始需求、判断需求类型、把需求路由给对应的"业务线"。它不负责具体执行，也不深入细节，这样设计的好处是顶层逻辑极其稳定，不会因为具体任务的变化而频繁改动。我见过太多项目把规划逻辑和执行逻辑揉在一个 agent 里，结果就是每加一个新任务类型，整个 prompt 都要重写，维护成本高得离谱。

受理层往下，是若干条业务线（line）。每条业务线对应一类任务，比如"信息调研线""内容生产线""数据处理线"。每条线内部有自己的专员 agent 和质检 agent。这种分层的好处是：新增一类任务，只需要新增一条业务线，完全不影响已有的线。这就是机构化带来的可扩展性。

2.2 三类核心角色与它们的职责边界

把骨架拆到最细，agency-agents里通常有这么三类角色，每一类的设计都有讲究：

这里有个特别容易被忽略的点：审核者必须和执行者使用不同的上下文。我早期做过一个实验，让同一个 agent 先执行再自审，结果它几乎从不认为自己有问题——因为它"记得"自己为什么这么做的，会本能地为自己的决策辩护。换成独立的审核 agent，只给它"任务要求"和"待审结果"，不给它执行过程，它的挑错能力立刻上了一个台阶。这个现象在业界被称为"自我评估偏差"，是设计多智能体系统时必须绕开的坑。

2.3 消息如何在 agent 之间流动

agent 之间怎么通信，直接决定了系统的稳定性和可调试性。常见的做法有三种：共享内存、消息队列、文件系统。agency-agents这类项目我建议用结构化消息 + 文件落盘的组合。

结构化消息指的是每条 agent 之间的通信都遵循固定 schema，至少包含：发送方、接收方、任务 ID、消息类型（请求/响应/通知）、载荷、时间戳。这样做的好处是任何一次协作都能被完整回放，出问题时可以精确定位是哪一步断了。

文件落盘则是把每个子任务的中间产物写成文件，而不是全塞在内存里。原因很实际：多智能体系统跑长任务时，上下文很容易撑爆，把中间结果落盘、只在需要时读取摘要，是控制上下文膨胀最有效的手段。我一般会让执行者产出结果后，写一个"结果摘要 + 完整结果文件路径"的消息传给下游，下游需要细节时再按路径读取。

提示：不要小看消息 schema 的设计。我踩过的最大一个坑就是早期用自由文本在 agent 间传消息，结果一个 agent 输出格式稍微变了一下，下游解析就崩了，而且崩得悄无声息。固定 schema 加上严格的解析校验，能省掉你无数个深夜调试的夜晚。

3. 让协作真正跑起来：任务编排的实操路径

3.1 从一句需求到一棵任务树

用户丢过来的需求通常是一句话，比如"帮我分析一下某个细分市场的竞争格局"。这句话对协调者来说太粗了，必须先变成一棵任务树。我的做法是让协调者按"目标-子目标-可执行动作"三层来拆：

• 第一层是总目标，就是用户那句话，原样保留，作为验收的最终标准。
• 第二层是子目标，比如"收集主要参与者信息""整理各家产品特点""对比价格区间""输出结论"。
• 第三层是可执行动作，每个子目标拆成 1 到 3 个具体动作，每个动作必须能被单个执行者在一次调用内完成。

这里的关键经验是：动作的粒度要控制在"一次工具调用能搞定"的范围。太粗了执行者会偷懒糊弄，太细了任务树会爆炸、协调开销超过执行本身。我一般会用一个简单的判断标准——如果这个动作需要执行者"先想一会儿再决定怎么做"，那它就还是太粗，得继续拆。

拆完之后，协调者不是立刻全部派发，而是先做一次依赖分析。哪些子任务之间有先后依赖，哪些可以并行，哪些必须等前面结果出来才能确定。把依赖关系理清楚，才能最大化并行度，缩短整体耗时。这一步很多人会跳过，结果就是所有任务串行执行，本来十分钟能跑完的活拖成一个小时。

3.2 执行者的上下文管理：别让它"记太多"

执行者最容易出的问题不是能力不够，而是上下文被无关信息污染。一个执行者如果既知道总目标、又知道所有兄弟任务的进展、还知道历史对话，它的注意力会被严重稀释，输出质量断崖式下跌。

我的做法是给每个执行者一个最小必要上下文：只给它当前子任务的描述、必要的输入数据、以及输出格式要求。总目标可以给它一句话作为背景，但绝不给它完整的任务树。这样它就能心无旁骛地把手头这件事做好。

具体操作上，我会在派发任务时构造一个这样的载荷：

{ "task_id": "subtask-003", "role": "executor", "objective": "整理三家主要参与者的产品定价区间", "inputs": { "source_files": ["research/participants.md"], "constraints": "只保留公开可查的价格，标注数据来源时间" }, "output_schema": { "type": "table", "columns": ["参与者", "产品线", "价格区间", "数据时间"] } }

注意output_schema这一项，它极其重要。不给执行者明确的输出结构，它就会自由发挥，下游解析起来痛苦不堪。给了 schema，它输出的东西就是机器可读的，整条流水线才能顺畅。

3.3 审核者的介入时机与返工策略

审核者什么时候介入，是个需要权衡的问题。全流程审核会拖慢速度，只在最后审核又可能让错误累积到无法挽回。我的经验是采用关键节点审核 + 终审的组合。

关键节点指的是那些"一旦错了后面全白干"的环节，比如任务拆解、核心数据采集。这些环节的结果必须先过审核，确认没问题再往下走。终审则是在所有子任务完成后，由审核者对照最初的总目标做一次整体验收。

返工策略上，我强烈建议设置返工次数上限，一般 2 次就够了。超过 2 次还达不到要求，说明要么任务拆解有问题，要么这个子任务本身超出了当前 agent 的能力边界，这时候应该把问题上报给协调者重新拆解，而不是让执行者无限重试。我见过一个项目因为没设上限，一个子任务返工了十几次，烧掉大量资源最后还是没做出来。

注意：返工时要给执行者具体的修改意见，而不是笼统地说"不合格"。审核者应该输出"哪里不对、为什么不对、期望是什么"三段式反馈，执行者拿到这种反馈的修复成功率，比拿到一句"重做"要高得多。

4. 那些文档里不会写的坑：我在实操中踩过的雷

4.1 无限循环：多智能体系统最隐蔽的杀手

多智能体系统最可怕的故障不是报错，而是静默的无限循环。A 把任务给 B，B 觉得这不该自己做又退回给 A，A 又转给 C，C 又转回 A……整个过程没有任何报错，日志看起来一切正常，但任务永远跑不完，资源却在持续消耗。

我第一次遇到这个问题时排查了很久，因为日志里全是正常的消息往来。后来才想明白，根因是角色职责边界模糊。当两个 agent 都觉得某个任务"可能该对方做"时，就会互相踢皮球。

解决办法有两个层面。一是在协议层加跳数限制：任何一条任务消息都带一个hop_count，每转手一次加一，超过阈值（我一般设 5）就强制上报给协调者裁决。二是在角色定义层把边界写死：每个 agent 的职责描述里明确列出"你不负责什么"，而不只是"你负责什么"。这个反向定义特别有用，能挡掉大量边界模糊导致的推诿。

4.2 上下文爆炸：长任务跑到一半就崩

跑长任务时，agent 的上下文会随着对话轮次不断累积，到某个点就超出模型窗口，要么报错，要么模型开始"遗忘"前面的内容。这个问题的隐蔽之处在于，它往往在任务进行到 70% 的时候才爆发，前面的工作全白费。

我的应对方案是滚动摘要 + 外部记忆。具体做法是：每当上下文累积到窗口的 60%，就触发一次摘要，把之前的对话压缩成一段结构化摘要（包含已完成事项、关键结论、待办事项），然后用摘要替换掉原始对话，继续往下跑。同时，所有重要的中间产物都落盘到文件系统，agent 需要时通过检索拿回来，而不是一直挂在上下文里。

这里有个细节：摘要本身也要控制质量。我见过摘要把关键约束条件漏掉的情况，导致后续 agent 完全跑偏。所以摘要生成后，我会让审核者快速过一遍，确认关键信息没丢。

4.3 工具调用的"幻觉成功"

执行者调用工具时，有一种特别坑的情况：工具实际失败了，但 agent 却报告"成功"。这通常发生在工具返回的错误信息不够明确，或者 agent 对返回结果做了过度乐观的解读时。

比如一个检索工具返回了空结果，agent 却理解成"没有相关信息，说明该情况不存在"，然后基于这个错误前提继续往下推理。这种错误会一路传播，最后产出一个看起来完整、实则建立在错误基础上的结果。

我的防御手段是强制工具结果校验。每个工具调用返回后，执行者必须先判断"这次调用是否真的拿到了有效数据"，判断标准写死在 prompt 里。拿不到有效数据时，必须走"重试或上报"分支，绝不允许基于空结果继续推理。这个规则看起来简单，但能挡掉相当一部分隐蔽的错误传播。

5. 从能跑到好用：性能与成本的平衡术

5.1 并行度不是越高越好

理论上，把任务树里所有无依赖的子任务并行执行，总耗时最短。但实际跑下来，并行度太高会带来两个问题：一是资源争抢导致单个任务变慢，二是协调开销急剧上升。我做过对比测试，在一个包含 20 个子任务的项目里，并行度从 4 提到 16，总耗时反而增加了约 30%，因为协调者要处理的消息量翻了四倍。

我的经验值是并行度控制在 4 到 8 之间，具体取决于任务类型。信息采集类任务可以高一些，因为彼此独立；需要共享中间结果的任务要低一些，因为同步成本高。这个值没有标准答案，得根据你自己的任务特征实测调优。

5.2 用"廉价模型做粗活，昂贵模型做细活"

多智能体系统跑起来后，成本会是个绕不开的问题。如果所有 agent 都用最强的模型，账单会很难看。我的策略是按角色分配模型：

• 协调者用中等模型即可，它的工作主要是拆解和路由，不需要太强的推理。
• 执行者里的"粗活"（比如格式转换、简单提取）用轻量模型。
• 执行者里的"细活"（比如分析、写作、复杂推理）和审核者用强模型。

这样搭配下来，整体成本通常能降一半以上，而质量损失很小。关键是要识别出哪些环节真正需要强模型，别一刀切。

5.3 缓存：被低估的省钱利器

多智能体系统里有很多重复计算。比如同一个子任务在不同轮次被反复执行，或者多个任务共享同一份背景资料。这些都可以通过缓存来省掉。

我一般会在两个层面做缓存：一是工具结果缓存，同样的检索请求短时间内不重复发起；二是子任务结果缓存，如果某个子任务的输入完全没变，直接复用上次的结果。缓存命中率上去了，成本和耗时都会明显下降。要注意的是缓存要有失效策略，数据类的结果不能缓存太久，否则会用到过期信息。

6. 这套架构还能往哪走：几个我验证过的扩展方向

6.1 引入"记忆"让机构越用越聪明

基础版的agency-agents每次任务都是"失忆"的，做完就忘。但一个真正的机构应该有积累。我尝试过给系统加一层长期记忆：把每次任务的成功经验、失败教训、常用模式都存下来，下次遇到类似任务时先检索历史，能显著提升效率和质量。

实现上，记忆层可以是一个向量库加一个结构化数据库。向量库存语义化的经验片段，结构化库存任务元数据（任务类型、耗时、成功率）。协调者在拆解新任务前先查一次记忆，看看有没有可复用的拆解模板，这一步往往能省掉大量重复思考。

6.2 让审核者学会"分级放行"

早期我让审核者对每个结果都做全量检查，效率很低。后来改成分级放行：低风险、格式规整的结果快速通过，只做格式校验；高风险、涉及关键结论的结果才做深度审核。这个分级规则可以根据历史数据动态调整——某个执行者在某类任务上历史准确率高，它的结果就可以走快速通道。

这套机制跑顺之后，整体吞吐量提升很明显，因为审核这个环节从"瓶颈"变成了"智能闸门"。

6.3 人机协同：把关键决策留给人

再强的多智能体系统，也不该在所有环节都全自动。我的做法是在关键决策点设置人工确认：比如任务拆解完成后、最终结果输出前，让人快速过一眼。这不是不信任系统，而是因为有些判断涉及业务偏好和风险取舍，机器很难完全替代人。

实操上，我会把这些确认点做成异步的——系统跑到确认点就暂停，把待确认内容推给人，人确认后系统继续。这样既不阻塞整体流程，又保证了关键环节的可控性。这套人机协同的模式，是我目前认为最务实的落地方式。

最后分享一个我反复验证过的心得：多智能体系统的复杂度增长是非线性的，每加一个 agent，交互路径可能翻倍。所以别一上来就追求"大而全"，先用最少的角色（协调者 + 执行者 + 审核者）把一条业务线跑通，跑稳了再扩展。我见过太多项目一上来就设计十几个 agent，结果连最基本的任务都跑不完，最后推倒重来。从最小可用系统起步，边跑边加，才是这类项目真正的落地节奏。