企业官网建设流程全解析

“agency-agents”这个项目代号，是我最近半年一直在折腾的一套多智能体协作系统的名字。第一次听到这个名字的人多半会问：到底什么意思？其实拆开看就很好理解——agency是“代理机构”，agents是“智能体”，合在一起，就是一支由多个AI智能体组成的“数字代理团队”。

我跟身边朋友聊得最多的一个问题是：多个AI智能体凑在一起，真的比一个全能AI助手更靠谱吗？为了验证这个想法，我做了这个项目。整个系统的设计思路很直接：把一家小型内容公司里不同岗位的分工复制到程序里，让智能体像同事一样协作完成一件事。这篇文章我就把项目怎么设计的、怎么一步步跑通的、以及我踩过哪些坑，全部拆开讲清楚，希望对打算上手多智能体或者在做自动化内容流程的同学有点帮助。

1. 项目概述：agency-agents到底解决什么问题

1.1 从“单个助手”到“智能体团队”

先说说最开始为什么想搞这个东西。单人用AI助手干活的时候，最常见的问题是：全程只有一个会话，所有任务都堆在同一个上下文里。你让它先搜集资料，再写初稿，再审核，再排版，它很容易在第二步就忘了第一步的某些细节，或者写到后面语气飘了、事实掺杂了，你回头还得自己重新捋一遍。

更麻烦的是，串行对话没办法并行。比如你要做十篇产品介绍，同一个助手只能一篇一篇来，中间你还要不断纠正它跑偏的方向。整个过程不是“自动化”，更像是“手动档加了个提示词”。

agency-agents的思路是把一条工作流拆成多个节点，每个节点由一个独立智能体负责。每个智能体只关心自己的输入、任务、输出，不背全流程的包袱。这样既解决了上下文混乱的问题，又能把不同岗位的要求分别写清楚，互相之间还多了一层“审查”关系——写手写完的东西有审校者把关，而不是一个人既当运动员又当裁判。

我当时定的目标很朴素：输入一个宽泛的主题，比如“智能家居入门指南”，系统能自动按流程产出结构完整、事实基本可靠、格式统一的Markdown文档。这个目标听起来不大，但真正做起来才发现，光是把几个智能体“串”在一起远远不够，难点全在任务拆解、消息传递和边界控制上。

1.2 标题里的agency-agents：一个“数字代理机构”的雏形

为什么非要用agency这个词？因为它的意思就是“代理机构、服务商”。你想想，一家做内容的小公司里，通常有这些岗位：有人负责分析选题方向，有人负责写稿，有人负责校对，有人负责最终检查能不能发布，还有人负责把成品交付给客户。

agency-agents就是在软件里模拟这套分工。我给它起了几个基础角色：研究分析师、内容写手、事实审校、合规质检、交付专员。每个角色都是一个独立配置的智能体实例，有自己的系统提示词、模型参数和输入输出格式。

这种拆法的好处在于：你改一个角色不会影响其他角色。比如写手风格需要调整，只改写手的提示词就行，审校逻辑完全不用动。你要是把五个角色的要求全写进一个提示词里，那牵一发而动全身，每次改完都心惊胆战。

我还特意比照真实团队管理的方式，给每个智能体规定了“产出物”。分析师必须输出选题结论和要点列表，写手必须输出完整初稿，审校必须输出问题清单，而不是一句“看起来不错”这种模糊结论。有了明确的产物格式，后续节点才能稳定地拿到输入。

1.3 它适合谁、不适合谁

做完这个项目之后，我给它的能力边界画了一个圈。先说适合的场景。

• 内容批量生产：每周要产出一批结构类似的文章、商品描述、公告，完全可以让团队里的智能体跑流水线。
• 信息整理聚合：给你一堆零散的资料、笔记、对话记录，让分析角色先分类，再由整理角色形成结构化的摘要。
• 流程化任务：只要是输入输出边界清晰、步骤稳定的任务，比如竞品信息汇总、周报草拟、FAQ生成，都很适合拆成智能体团队。

不适合的场景也有几个。第一，任务目标本身极度模糊，比如“帮我做一个好用的东西”，连验收标准都没有，多智能体反而会把跑偏放得更大。第二，强实时交互的场景，比如用户要一个聊天机器人，这种要的是低延迟对话，而不是动辄十几秒的多节点流水线。第三，涉及个人隐私或敏感权限的高风险操作，我是不建议完全交给自动流程去做的，必须保留人工审批节点。

2. 核心架构与角色编排

2.1 五个基础角色的职责与产物

这一节说下我实际落地时给每个角色定的职责边界。先看角色表，后面再解释为什么这么分。

分析师这个角色很关键。它是所有智能体里的“头”，负责把用户一句模糊的话翻译成可执行的任务。比如用户说“写一篇关于如何选择智能门锁的文章”，分析师不能直接丢给写手，而是要拆出目标人群、核心对比维度、需要核实的参数点、文章结构建议。

你不能让写手一边写作一边做事实核查，否则出现矛盾时它通常选择“顺下去”，而不是“停下来查”。所以事实审校必须独立。同样，审校也会漏掉一些表达规范问题，所以后面还要有合规质检兜底。

最后交付专员看起来简单，其实解决了一个很现实的问题：不同节点的输出格式经常不统一。写手返回的是几千字正文，审校返回的是带批注内容的格式，交付专员要统一成最终交付格式。它就像一个项目助理，负责把其他同事的成果整理成客户能直接用、不丢格式的文件。

2.2 为什么要拆角色，而不是塞进一个提示词

你可能觉得，用一个大模型加一段长提示词不也能干这些事吗？我在项目初期就是这么干的，实测效果很差。

第一次尝试，我把“你要先分析、再写作、再自查、再优化”全部写进一个系统提示词。单看一篇输出，质量还行，但一旦任务复杂一些，比如子任务之间跨度很大，模型会开始混淆优先级。它会写着写着，忘了自己前面刚总结过哪些要点，还会在审校环节自我辩护：“这段虽然可能不准，但结合上下文……”这种自我圆场的现象非常普遍，因为单个模型天然倾向于生成连贯文本，而不是做严格批判。

拆成独立智能体之后，每个角色只需要遵循自己那一小段规则。审校角色不需要“优雅行文”，它可以很直接地说“第二段的XX数据需要重新核实，因为没有给出来源”。这种粗糙但明确的输出，恰恰是自动化流程需要的。

还有一个附带的好处是并行性。如果任务量大，研究分析做完大纲后，可以同时派发给两个写手分别写不同章节，之后再合并。单智能体模式做不到这个，它只能老老实实从头写到尾。

2.3 模型选型与角色对应的配置

不同角色适合的模型配置差别很大。我一开始用同一个大模型配置跑所有角色，结果成本高，效果也没到位。后来改成按角色配参数，情况立刻好转。

研究分析师需要较强的推理能力，要能从模糊需求里抓重点、找知识盲区，所以我给它用推理能力更强的模型，温度调低，基本控制在0到0.3之间。这是为了让“拆解”这一步更稳定，不天马行空乱编大纲。

内容写手反而不一定用最强的推理模型，我更看重语言组织能力，温度会适当调高一点，比如0.7到0.8。让它在框架内有一点发挥空间，语句更自然，不显得呆板。

事实审校这个角色对参数很敏感。它需要严格的比对、怀疑能力，但是大模型本身并不擅长“承认自己不知道”。所以我把审校的温度调成0，同时提示词里强制要求：每个结论必须标注“可确认”或“需人工核查”，如果资料里没有依据，不许自己脑补。

合规质检比较特殊，它更像规则引擎加模型判断的混合体。提示词里我写了一批硬性规则，比如“不得出现绝对化承诺”、“不得出现未经验证的数据”、“格式必须符合模板”。这些规则先交给正则和字符串匹配跑一遍，再过一遍模型做语义判断，双保险。

下表是我后来固定下来的一组参考配置：

3. 任务编排与协作流：让多个智能体真正“配合”起来

3.1 主控节点、任务队列和状态流转

多个智能体只是“有人了”，要让他们真正协作起来，还得有个统一调度的“主控”。在我的系统里，这个主控不是智能体，而是一段代码流程，负责建任务、推进状态、分发消息、收集结果。

我用的是最简单但很可靠的方案：每个任务进来，先生成一个唯一任务ID，然后把任务状态存入数据库（当时用的SQLite，后来数据量大了换成了常见的开源关系型数据库）。任务状态就几个：待拆解、分析中、写作中、审校中、质检中、完成、失败待重试。

为什么要单独维护一套状态？因为智能体的调用是异步的，主控发起一个模型请求后，可能要等几十秒才有返回。如果没有状态记录，中间进程一重启，任务就丢了，全得重来。有了状态和任务表，主控重启后可以扫描“未完成”的任务继续推进。

当然这里要说明，这只是我基于常见实践做的简化设计。如果你有更大的并发量，可以上专业的任务队列组件，把每个请求丢进队列，再由一组工作进程消费。但基本原理是一样的：任务是消息，智能体是消费者，状态是数据库里的一行记录，仅此而已。

3.2 智能体之间怎么传结果

智能体之间传结果，比我想象中更容易出错。第一次做的时候，我让主控把上一个节点的原始输出直接塞进下一个节点的输入里。结果审校阶段的输入里塞了写手一整篇几千字的文章，再让审校输出问题清单，模型经常只关注前面一小段，后面的内容被“忽略”了。

后来我统一了消息结构，用JSON包一层，核心字段大概是：

{ "task_id": "任务全局ID", "node_id": "当前节点", "input_text": "上一节点产出的核心文本", "meta": { "source_version": "初稿_v2", "previous_node": "writer", "model_used": "content_model_v3" } }

这里有个小技巧：input_text不要总是塞全文。如果一个节点只需要上一节点的摘要或结论，就只传那部分。比如交付专员只需要最终的正文和质检结论，就不需要分析师那时候的完整背景资料，传多了反而占用上下文、增加干扰。

另外，长文本最好用文件路径引用，而不是直接塞进消息体。我的做法是：写手生成的初稿落盘成一个临时文件，消息里带路径。审校节点读取文件内容做处理。这样消息体积小，出问题时也方便人工去查文件内容。

3.3 上下文窗口的三个关键开关

多智能体流程里，上下文管理是我觉得最值得研究的部分。每个模型调用都有上下文窗口限制，而且就算窗口够大，塞进去的无关内容多了，输出质量也会下降。我总结出三个必须控制的开关。

第一个是裁剪开关。传给下游节点的内容，只保留与当前任务直接相关的部分。比如审校节点需要的只是文章正文，那我就在调用前把格式、临时备注等因素去掉，让它看到“干净的正文”。

第二个是摘要替代开关。当一个节点需要“前面发生过什么”的时候，不传整段历史，而是传经过压缩的摘要。比如写手写初稿前，不需要看分析师的完整工作过程，只需要看“最终拆解出的三个写作要点”。这个摘要可以由分析师节点在最终输出里自带上，也可以由主控用一个独立摘要调用来生成。

第三个是引用限制开关。如果某个节点需要参考比较多的外部资料，不让它一次性读几十篇，而是先让分析师挑选最相关的三个来源，用引用形式传进上下文。超过三篇时，另建一份“背景资料库”文件，只传文件索引部分内容。这样做的好处是减少模型记住不关键信息，也更方便找回原始出处。

4. 实操记录：从零到可用的最小闭环

4.1 一个内容产出链路是怎么跑通的

理论说了不少，回到实际操作。下面我用一个具体任务来展示我的系统实际跑一遍的流程：输入是“写一篇智能家居入门指南”。

第一步，主控收到任务，生成任务ID，状态置为“待拆解”，调用研究分析师。我传给分析师的提示词大意是：先明确这篇文章的目标读者，再拆出5到7个章节主题，每个章节给出三个关键要点，最后给出需要核实的信息清单。分析师输出的内容包括“目标读者：刚搬新家、想尝试入门智能家居的普通用户”、“核心章节：智能音箱、智能照明、安防设备、选购注意事项”等。我把这些结果存入任务数据表。

第二步，状态变为“写作中”，主控把分析师要点传给内容写手。写手的输入包括标题、章节结构和每个章节的要点提示。它逐章生成初稿。这里我遇到的第一个实际问题是：模型写长文到第三章之后，会开始重复第一章里说过的内容。我的对策是让写手分成多次调用来写，每次只写一个章节，而不是让它一次性写一整篇。写完每个章节后，主控把已写章节的标题和摘要追加给写手，保持它们的连贯性。

第三步，整篇初稿写完后，状态变成“审校中”。事实审校开始逐个章节检查，输出问题清单。实际跑下来，它每次能挑出两三个值得注意的问题，比如某个卖点数据是推测值但没有说明，某个品牌对比不够客观，建议增加参考来源。这些问题我让主控自动退回给写手做第二轮修改。

第四步，修改稿进入合规质检。这一关用了规则加模型双重判断，比如检查是否含“最”“第一”等绝对化词汇，以及是否有不合理的夸大表述。质检如果不通过，会生成具体修改意见替换对应段落。

第五步，交付专员把所有通过查检的章节合并，补上前言和目录，统一标题层级，输出一个标准格式的Markdown文件。整个过程跑完大概需要三到五分钟，如果只是简单主题，通常两分钟左右就能出成品。

4.2 并发、超时与重试的取舍

落地这一步，不得不面对三个现实问题：并发、超时和重试。

最开始我是串行调用，一个任务从头到尾一个节点一个节点跑。好处是逻辑简单，坏处是太慢。后来我把主控改造成可并行的：用户在配置里可以设置最大并发任务数，不同任务之间可以同时跑，同一个任务里如果出现多个可独立执行的子任务，也能并行。

并发不是越大越好。模型服务接口通常有速率限制，并发太高会被限流，甚至出现大量超时。我实际测下来，单机跑中等规模任务，并发控制在5到8个请求之间比较稳，具体还是要看你的模型服务商限制。另外，并发高了以后，成本会迅速上涨，这点后面细说。

超时处理我也踩过坑。模型调用接口偶尔会慢，一个请求可能卡很久。一开始我把超时设成120秒，结果有个任务等了一个多小时还在转圈。后来我把超时设为60秒，超过就重试，并且用指数退避策略，第一次重试等10秒，第二次20秒，第三次40秒，最多重试三次。超过三次就标记为“失败待人工处理”，不强行重复烧钱。

这里有一个我自己觉得特别重要的教训：不要对所有节点用统一的超时时间。写手节点生成大段内容，耗时天然比质检节点长，要给足余量。质检、关键字检查这类轻量节点，超时设短一点，比如20秒，这样能让整个链路快速失败、尽快换条路走。

4.3 成本与速度的平衡：我的一组实测数据

多智能体比单次模型调用贵非常多，因为一次完整流程会有七八次甚至更多次模型调用。我刚开始跑的时候没在意，跑完一个复杂任务一看账单，比我预想的高了好几倍。

做个简单估算：一次完整内容任务调用分析师一次、写手按章节分三次、审校一次、质检两次、交付整理一次，加起来至少7次模型调用。假设平均每次调用消耗2500个token，一次任务就是17500个token。按当时的模型价格粗略算，一次任务成本可能在几毛到几块钱人民币之间，具体取决于你用的模型。一个月跑几百个任务，成本就不可忽视了。

省成本的几个办法我试验下来比较有效：

• 缓存历史结果：同一个类型的任务、同一个模板，如果分析师的输出与过去某个任务高度相似，直接命中缓存，跳过这一步。
• 审校通过后不重复跑全文：只有修改过的局部段落才重新过检，而不是整篇重新审。
• 分层模型组合：轻量级任务用便宜模型，只有复杂推理节点才用强模型。
• 对输出做长度约束：写手节点设置更合理的最大token，防止它废话连篇导致后面每个节点成本都跟着涨。

速度上，影响最大的是“长文本从头到尾写”。拆成章节并行写之后，速度提升明显。如果是三章内容，并行跑比串行大概快了一半多。不过要注意，并行写作带来的风格差异需要审校节点多一道“语气统一”检查，否则不同章节看起像不同人写的。

5. 踩坑实录与排查心得

5.1 常见问题速查表

多智能体系统刚搭起来的时候，问题比想象中多。这里直接放一个我整理过的问题表，都是我自己实际遇到并解决的。

每个问题基本都跟“边界感”有关。多智能体系统的健壮性，很大程度不取决于单个模型多聪明，而在于你有没有把每个节点的职责边界、输入边界、输出边界用代码和提示词一起钉死。

5.2 防死循环和结果“失控”

自动流程最怕的就是死循环和不收敛。最常见的一种失控场景是：审校挑出问题，写手修改，审校又挑出一个新问题，写手又改，循环往复。理论上这种迭代可以让质量越来越好，但实际运行中经常变成无限改稿，成本直线上升。

我的做法是给整个任务设置最大迭代次数。比如写手与审校之间的往返最多两轮，两轮之后如果仍有未解决问题，把问题收集好直接进入人工确认队列，不再自动改。

还有一种失控情况是智能体开始“自说自话”。比如写手在写作时为了丰富内容，凭空编了一个不存在的功能特性。审校没注意到，因为审校的知识储备里正好没有这个特性的明确信息，模型就倾向于“信了”。这个只能靠约束来缓解：在写手的系统提示词里强制写上“如果无法从资料里确认细节，必须标注‘待确认’，不得自行补齐说法”。

稍微进阶一点的方案是给主控加一个结果相似度检测：如果同一节点连续两次输出的文本相似度超过90%，就判定陷入原地打转，主动终止该分支并通知人工。这个检测可以用简单的开源文本相似度做过计算，嵌入到主控逻辑里，花不了多少代码量，却很管用。

5.3 从Demo到可运维的小改造

很多人的多智能体项目停在“demo能跑”的阶段，但如果要长期使用，就得做一些偏工程化的改造。

第一项是日志。我一开始只记录每步的最终输出，后来发现出问题时根本没法定位，因为不知道中间发生了什么。于是我给每个节点加了结构化日志，包含：任务ID、节点名、开始时间、结束时间、输入摘要、输出摘要、耗时、token数、调用模型。这套日志后来成了最常用的排查工具。

第二项是任务重放。保存了完整的输入输出之后，遇到某个任务结果很差，我可以直接把同一份输入重新喂给同一个节点，用来测试修改后的提示词是否有效。这比凭感觉调提示词靠谱得多。

第三项是人工介入接口。系统里所有“拿不准”的地方，我都留了人工标记位。比如质检发现敏感信息但置信度不高，它不会直接删除内容，而是打上“待人工确认”标签，由人来决定。这样我就不用整天提心吊胆怕自动流程闯祸。

6. 后续还能怎么扩展，以及我的一点个人体会

写到这儿该说点实际感受了。我最深的体会是，多智能体系统的瓶颈通常不在单个模型的能力，而在任务拆解和信息传递。模型本身再强，你让它在混乱的上下文里干活，输出也不会稳定；反过来，只要把职责拆清楚、传参规范、边界钉死，哪怕每个节点用普通水平的模型，整体效果也能超出预期。

这个项目目前还在继续扩展，我最想加进去的是两样东西。一是简单的记忆模块，让每个角色能记住自己在这个任务里做过哪些关键判断，而不只靠当前这一步的输入。二是更细粒度的成本监控，把每个任务的token消耗按角色统计成报表，用来评估哪个环节最值得优化。目前很多功能我还是手工配置加脚本处理，后续会逐步往更自动化的方向走。

如果你也想试类似的系统，建议不要一上来就搭十个角色、五层流程。先从两个角色开始，比如分析师加写手，把一条最窄的链路跑通，观察输出的稳定性和成本。再根据实际情况逐步加审校、质检、交付这些角色。多智能体不是角色越多越好，而是每多一个角色，就要多处理一层偏差和成本，这个度需要自己慢慢找。