企业官网建设流程全解析

1. 从“agency-agents”这个标题说起：它到底在解决什么问题

第一次看到“agency-agents”这个组合词，我脑子里蹦出来的第一反应是：这大概率是一个围绕“代理”和“智能体”做文章的项目，而且不是那种玩具级的单文件脚本，更像是一套有组织、有分工、能协作的体系。事实也确实如此。把这两个词拆开看，“agency”强调的是代理关系、委托执行、任务转交，而“agents”则指向一个个具备独立执行能力的智能体单元。合在一起，它描述的是一套让多个智能体像一家小型代理公司那样运转的架构——有人接单、有人拆活、有人干活、有人验收。

这套东西能做什么？简单说，它把原本需要人来回切换、手动串联的复杂任务，交给一组各司其职的智能体去协同完成。比如你丢进去一个模糊的需求，它不会直接硬着头皮瞎干，而是先由一个“调度型”智能体把需求拆成若干子任务，再分发给对应的“执行型”智能体，最后汇总结果、做一致性检查。整个过程像极了一个小型工作室的运作方式：项目经理接需求，设计师出方案，工程师落地，质检把关。

它解决的核心痛点有三个。第一是单智能体的能力天花板——一个模型再强，面对跨领域、多步骤的任务也容易顾此失彼，而多智能体分工能把复杂度摊薄。第二是任务流转的自动化——过去很多流程靠人手动复制粘贴、来回切换工具，现在可以交给代理层去编排。第三是结果的可控性——通过引入专门的校验角色，能在流程内部就把明显错误拦下来，而不是等交付后才发现。

适合谁来参考？如果你已经在用单个智能体处理日常任务，但发现稍微复杂一点就力不从心，那这套思路对你很有价值。如果你是从零开始接触智能体编排，也不用慌，我会把架构、角色划分、通信机制、落地步骤都拆开讲，尽量让不同基础的人都能照着搭出一个能跑的版本。下面我按“设计思路—核心细节—实操落地—问题排查”的顺序，把我在实际搭建中踩过的坑和总结的经验一并倒出来。

2. 整体架构设计与角色分工思路

2.1 为什么是“代理公司”而不是“流水线”

很多人一提多智能体，第一反应是搭一条流水线：A做完交给B，B做完交给C。这种线性结构在任务步骤固定、依赖关系明确时确实好用，但一旦任务分支变多、需要反复迭代，流水线就会变得又长又脆。agency-agents 的思路更接近“代理公司”，核心区别在于：角色是围绕职责定义的，而不是围绕步骤定义的。

我举个具体例子。假设任务是“做一份竞品分析报告”。流水线思维会拆成：搜集资料→整理数据→撰写报告→校对。而代理公司思维会定义几个角色：调研员负责信息采集与交叉验证，分析师负责提炼结论，撰稿人负责成文，审核员负责事实与逻辑校验。区别在哪？当调研员发现某个数据源不可靠时，它可以主动回头补充调研，而不是把问题一路带到校对环节才暴露。这种“职责驱动”的设计，让系统具备了自我纠偏的空间。

从工程角度看，职责驱动的另一个好处是可复用。同一个“审核员”角色，既能审报告，也能审代码、审方案，只要给它配上对应的校验规则即可。而流水线里的“校对步骤”往往和具体任务强绑定，换个场景就得重写。

2.2 三类核心角色的划分逻辑

在实际搭建中，我把角色收敛成三大类，这个划分方式经过多次调整后我觉得最稳：

• 调度类（Orchestrator）：负责接收原始需求、拆解任务、分配工作、跟踪进度、处理异常。它是整个系统的大脑，但不直接干具体活。
• 执行类（Worker）：负责实际产出，比如检索、计算、写作、生成代码。每个执行体只专注自己那一块，边界清晰。
• 校验类（Validator）：负责对执行结果做检查，包括格式校验、事实核对、逻辑一致性检查。它是最后一道防线。

为什么要把校验单独拎出来？因为我在早期版本里把校验逻辑塞进执行体内部，结果发现执行体既当运动员又当裁判，很容易“自我感觉良好”，明明输出有问题却给自己放行。把校验独立成角色后，相当于引入了一个外部视角，拦截率明显提升。

提示：角色数量不是越多越好。我试过拆出七八个角色，结果通信开销暴涨，调度逻辑复杂到难以维护。三个大类、每个大类下两到四个具体角色，是我实测下来比较舒服的区间。

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

角色之间怎么说话，是架构设计里第二个关键决策。常见方案有两种：一是消息总线，所有角色往总线发消息、从总线取消息；二是直接调用，调度器直接调用某个执行体并等待返回。

我最终选的是混合模式：调度与执行之间用直接调用，保证时序可控；执行体之间的信息共享走轻量消息队列，避免互相阻塞。这么设计的原因很实际——如果全用消息总线，调试时会很难追踪一条任务到底流经了哪些环节；如果全用直接调用，又会出现某个执行体卡住导致整条链路僵死的情况。

具体实现上，我用一个中心化的任务表来记录每个子任务的状态（待处理、进行中、已完成、失败），调度器轮询这张表来推进流程。执行体完成任务后更新状态并写入结果，校验体读取结果做检查。这套机制不复杂，但足够稳，出问题时看一眼任务表就能定位卡在哪。

3. 核心细节解析与实操要点

3.1 任务拆解：把模糊需求变成可执行清单

整个系统里最容易翻车的地方，不是执行，而是拆解。需求拆得粗，执行体不知道从哪下手；拆得细，又容易把简单任务切得七零八落，增加协调成本。我的经验是遵循“一个子任务对应一个明确产出物”的原则。

比如“帮我分析一下最近三个月的销售数据”这个需求，我会拆成：拉取原始数据（产出：数据文件）、清洗异常值（产出：清洗后数据）、计算关键指标（产出：指标表）、生成分析结论（产出：文字结论）。每个子任务都有看得见摸得着的产出，执行体不会迷茫，校验体也有明确的检查对象。

拆解这一步我建议由调度类角色来做，但要给它配一份“拆解模板”。模板里规定常见任务类型的标准拆法，比如分析类任务至少包含数据获取、处理、计算、结论四步。有了模板兜底，拆解质量会稳定很多，不会因为输入措辞的变化而忽好忽坏。

3.2 上下文传递：别让执行体“失忆”

多智能体协作里一个隐蔽的坑是上下文丢失。执行体A产出的结果，执行体B可能只拿到一部分，导致B基于残缺信息干活。我踩过这个坑：调研员整理了一份带来源标注的资料，结果分析师只拿到了结论没拿到来源，最后报告里出现了无法追溯的数据。

解决办法是结构化传递。每个子任务的产出不只是一段文本，而是一个包含“内容、来源、置信度、依赖项”的结构化对象。执行体在开始工作前，先读取自己依赖的那些对象，确认信息完整再动手。如果发现依赖缺失，就向调度器报错，而不是硬着头皮猜。

这里有个细节值得说：置信度这个字段很有用。调研员对某条信息把握不大时，可以标一个低置信度，分析师看到后就会谨慎使用，或者要求补充验证。这种“带不确定性的传递”比假装什么都确定要诚实得多，也更接近真实工作场景。

3.3 校验规则：从格式到逻辑的分层检查

校验类角色的工作我分成三层来做，层层递进：

1. 格式层：检查产出是否符合约定的结构，比如JSON字段是否齐全、必填项是否为空。这层用规则引擎就能搞定，速度快、成本低。
2. 事实层：检查关键数据、引用是否有来源支撑，数字前后是否一致。这层需要执行体提供来源信息，校验体做交叉比对。
3. 逻辑层：检查结论是否由数据推导而来，有没有跳跃或矛盾。这层最难，我目前的做法是让校验体扮演“挑刺的审稿人”，专门找逻辑漏洞，而不是判断对错。

三层检查的通过标准不一样。格式层必须全过，事实层允许标注存疑，逻辑层则输出修改建议。这样既保证了底线质量，又不会因为过度严格导致流程频繁中断。

注意：校验体本身也可能出错。我遇到过校验体把正确结果误判为错误的情况。所以校验结论也要记录，定期人工抽查校验体的判断准确率，必要时调整它的提示词或规则。

4. 实操过程与核心环节实现

4.1 环境准备与基础框架搭建

动手之前先把地基打好。我用的是Python生态，核心依赖就几个：一个用于调用模型能力的客户端库、一个轻量任务队列、一个结构化数据存储。不需要上重型框架，多智能体编排的本质是流程控制，用不着把简单问题复杂化。

目录结构我建议这样组织：

agency_agents/ ├── orchestrator/ # 调度类角色 │ ├── planner.py # 任务拆解 │ └── dispatcher.py # 任务分发与状态跟踪 ├── workers/ # 执行类角色 │ ├── retriever.py # 信息检索 │ ├── analyst.py # 分析计算 │ └── writer.py # 内容生成 ├── validators/ # 校验类角色 │ ├── format_check.py │ └── fact_check.py ├── core/ │ ├── task_table.py # 任务状态表 │ └── message.py # 结构化消息定义 └── config/ └── roles.yaml # 角色配置

把角色配置抽到YAML里是个好习惯。每个角色的提示词、可用工具、依赖关系都写在配置里，改角色行为不用动代码，改配置就行。我早期把提示词硬编码在Python文件里，后来调整一次要翻好几个文件，非常痛苦。

4.2 调度器的实现要点

调度器是整个系统的心脏，它的核心逻辑是一个循环：读取任务表→找出可执行的任务→分发给对应执行体→等待结果→更新状态→检查是否全部完成。听起来简单，但有几个细节决定成败。

第一是并发控制。有些任务可以并行，有些必须串行。我在任务定义里加了一个depends_on字段，调度器只分发依赖已满足的任务。这样既利用了并行能力，又不会打乱依赖顺序。

第二是超时处理。执行体可能因为各种原因卡住，调度器必须设置超时。超时后把任务标记为失败，并触发重试或降级策略。我一般设三次重试，三次都失败就转人工处理，避免无限循环。

第三是状态持久化。任务表要落盘，不能只放内存。否则程序一崩，所有进度全丢。我用的是轻量数据库，每次状态变更都写一次，虽然有点开销，但换来的是崩溃后可恢复。

# 调度器核心循环的简化示意 def run(self): while not self.task_table.all_done(): ready = self.task_table.get_ready_tasks() for task in ready: if self._check_timeout(task): self._handle_timeout(task) continue worker = self._pick_worker(task) result = worker.execute(task) self.task_table.update(task.id, result) self.task_table.persist()

4.3 执行体的提示词设计

执行体的产出质量，八成取决于提示词。我总结了一个“四段式”提示词结构，实测比一大段描述效果好很多：

• 角色声明：明确告诉它“你是一个专注于XX的执行体”。
• 任务描述：当前要做的具体子任务，以及期望的产出格式。
• 上下文注入：它依赖的前置结果，结构化传入。
• 约束条件：不能做什么、遇到不确定时怎么办。

第四段最容易被忽略，但恰恰最重要。比如我会明确写“如果依赖数据缺失，不要猜测，直接返回错误码MISSING_DEP”，这样调度器就能识别并处理，而不是拿到一段编造的内容。

4.4 校验体的落地方式

校验体我做成可插拔的。每个校验体实现一个统一的接口：输入是待校验对象，输出是校验报告（通过/不通过/存疑，附说明）。调度器根据任务类型决定挂载哪些校验体。

格式校验用代码规则实现，快且准。事实校验和逻辑校验则调用模型能力，提示词里强调“只找问题，不给修改方案”，避免校验体越俎代庖去重写内容。这个边界很重要，否则校验体会变成第二个执行体，职责就混了。

4.5 一次完整任务的运行记录

我拿一个模拟任务跑了一遍完整流程，记录如下：

整个流程跑下来约44秒，中间有一次存疑标注触发了补充检索，额外花了10秒。这个开销我认为是值得的，因为最终报告里那条存疑数据被明确标注了来源不确定性，而不是被当成确定事实写进去。

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

5.1 执行体“自作主张”怎么办

这是最常见的问题。执行体拿到任务后，不按约定的产出格式来，或者擅自扩大了任务范围。我的排查思路是三步走：先看提示词里约束条件是否写清楚，再看上下文注入是否完整，最后看是不是任务本身定义得太模糊。

多数情况下问题出在约束条件。我后来养成了一个习惯：每个执行体的提示词末尾都加一句“严格按以下格式输出，不要添加额外内容”，并附上格式示例。加了这句之后，格式跑偏的情况少了八成。

5.2 任务卡死或无限循环

调度器如果没做好超时和重试控制，很容易出现任务卡死。我遇到过一次：某个执行体因为依赖数据格式不对，反复重试同一个任务，把任务表刷了几百条记录。后来加了两个限制：单个任务最大重试次数，以及全局最大循环次数。超过阈值直接终止并报警，不再自动重试。

排查这类问题时，任务表是最好用的工具。看一眼哪些任务状态长期停留在“进行中”，基本就能定位到卡点。

5.3 校验体误报与漏报

校验体不是万能的。误报（把对的判成错的）会拖慢流程，漏报（把错的放过去）会损害质量。我的应对策略是分级处理：格式层误报直接修规则；事实层和逻辑层的误报，先记录样本，积累到一定数量后统一调整提示词。

漏报更难发现，因为错误已经流出去了。我的做法是定期人工抽查最终产出，发现漏报就回溯校验体的判断记录，看它当时为什么放行。这个过程有点像给校验体做“错题本”，坚持一段时间后它的判断会越来越准。

5.4 常见问题速查表

5.5 我踩过的几个坑

第一个坑是过早追求角色细分。一开始我就想搞出十几个角色，结果调度逻辑复杂到自己都理不清。后来砍到三类核心角色，系统反而更稳。角色划分要服务于流程清晰，而不是追求看起来专业。

第二个坑是忽略日志。早期我没做详细日志，出问题只能靠猜。后来每个角色的输入输出、状态变更、校验结论全部落日志，排查效率提升了一个量级。日志不是可选项，是必需品。

第三个坑是把校验体当摆设。有段时间我觉得校验拖慢速度，就把它关了，结果产出质量肉眼可见地下滑。校验的价值不在于拦住多少错误，而在于它让执行体知道“有人会检查”，从而在生成时就更加谨慎。

6. 性能调优与扩展方向

6.1 让流程跑得更快的几个手段

系统能跑通之后，下一步就是让它跑得快。我试过几个手段，效果比较明显的有三个。

并行化无依赖任务。把任务依赖图理清楚后，会发现很多任务其实可以同时跑。比如信息检索的多个来源可以并行拉取，分析计算的多个指标可以并行算。我实测并行化后整体耗时下降了约四成。

缓存重复调用。同一个执行体在相似任务上可能反复调用模型，如果输入高度相似，可以缓存结果。我加了一层基于输入哈希的缓存，命中率大概三成，省下的时间很可观。

精简上下文。上下文不是越多越好，塞太多无关信息反而拖慢执行体、干扰判断。我后来只注入直接依赖的结果，间接依赖用摘要代替，速度和准确率都有改善。

6.2 扩展新角色的正确姿势

系统跑顺之后，加新角色是常有的事。我的经验是：先加校验角色，再加执行角色。因为校验角色是只读的，加进去不会打乱现有流程，风险低。执行角色会改变任务流，加之前要先想清楚它在哪个环节介入、依赖什么、产出什么。

加新角色时，配置文件的改动要同步更新依赖关系。我见过有人加了执行体但忘了更新调度器的角色映射，结果任务分发时找不到对应执行体，直接报错。这种低级错误靠配置校验能避免——启动时检查所有任务类型是否都有对应执行体。

6.3 从单机到分布式的演进思路

单机跑得动就别急着上分布式。我见过不少项目，任务量根本没到瓶颈，就先搞了一套复杂的分布式调度，结果维护成本远超收益。真正需要分布式的时候，通常是执行体调用外部资源有速率限制，或者任务量大到单机排队太久。

演进路径我建议这样走：单机多线程→单机多进程→多机分布式。每一步都先确认当前架构真的到了瓶颈，再往下一步走。分布式带来的网络通信、状态同步、故障恢复问题，会成倍增加复杂度，不到万不得已不要碰。

7. 关于这套架构我个人的几点体会

搭完并跑了一段时间后，我最大的体会是：多智能体系统的难点从来不在智能体本身，而在它们之间的协作规则。单个执行体的能力，现在的模型基本都够用；真正决定系统好不好用的，是任务怎么拆、上下文怎么传、错误怎么处理、质量怎么保证。这些“胶水”部分才是需要花心思的地方。

另一个体会是，不要追求全自动。我早期总想着让系统从头到尾无人干预，结果发现有些环节人工介入一下，整体效率反而更高。比如任务拆解后让人确认一眼，能避免后面一大堆返工。现在我更倾向于把系统设计成“人在关键节点上把关”的模式，而不是追求完全无人值守。

最后一个建议：从小场景开始。别一上来就搞一个能处理所有任务的通用系统，先挑一个具体、边界清晰的场景跑通，把协作机制打磨顺，再逐步扩展。我见过太多项目死在“想做大而全”上，反而是那些从一个小需求切入、慢慢长出来的系统活得最久。

这套东西后续还能往几个方向扩展：一是接入更多类型的执行体，比如专门处理图像、音频的角色；二是把校验规则做成可学习的，让系统从历史错误中自动总结检查点；三是把任务表做成可视化的，方便实时观察流程状态。这些我都还在摸索，有新的心得再拿出来分享。