去年我接了一个行业分析报告的项目要求一周内产出一份覆盖市场数据、技术路线、竞争格局的完整文档。最初我图省事把几十页资料和需求一股脑丢给一个AI助手来回对话了十几轮结果前半段看着还行后半段开始原地复读数字前后对不上甚至把上一版讨论过的错误结论又捡了回来。后来我换了个思路——把任务拆开交给一群各司其职、互相协作的智能体去执行效果立刻不一样了最终报告不仅按时交掉还通过了客户的三轮审阅。这个思路在圈子里有个非常形象的名字agency-agents也常写成 agent-agency字面意思是智能体代理机构。它要做的事情就是把传统广告公司、咨询公司里项目经理拆需求、研究员找资料、写手出内容、编辑做质检那一套项目制协作方式完整搬到 AI 智能体世界里。这篇博文我会从为什么单一大模型不够用讲起然后逐步拆解整套系统的角色设计、协作协议、工具接入、运行流程、踩坑排障和质量兜底方案适合正在用大模型处理复杂任务的开发者、内容团队和数据分析师参考。1. 为什么单一大模型搞不定一整摊子任务很多人的第一反应是既然大模型这么强把任务说清楚点不就行了我在没做这套系统之前也是这么想的。但连续跑了几次长任务之后我发现问题根本不是提示词写得不够好而是单模型单上下文的工作方式本身就有天花板。1.1 单次对话的天花板上下文窗口与注意力衰减先说我实测观察到的一个规律。当我把一份包含五千字需求描述和二十份资料片段塞进同一条对话时模型在前半段还能严格遵守指令到了中后段就开始出现三种典型症状一是遗忘最初的约束条件比如开头要求必须标注数据来源写到后面直接裸奔二是自我重复同一个论点换着说法出现三遍三是错误积累前文一个计算错误后文基于这个错误继续推导越错越离谱。这背后其实是两个机制在起作用。第一是上下文窗口有限超长输入会被截断或者被模型内部压缩处理关键信息可能落在截断区之外。第二是注意力衰减就算所有内容都在窗口内模型对距离当前位置越远的信息关注度越低。你可以把它理解成让一个实习生从市场调研干到排版校对连续干十个小时前五个小时记得甲方要求后五个小时基本靠想象补全。我用同一个任务做过对照整体输入时内容准确率大概只有七成左右而且后期生成的内容明显质量下滑把同样的任务拆成五个子任务、每个子任务独立上下文去执行每个子任务的输出稳定性和准确率都明显上升因为每个模型的注意力只需要集中在一小片区域上。1.2 为什么机构化协作优于加强提示词那有人会说我把提示词写得极其详细每一步都要求模型自我检查不就行了这一步我确实也试过但效果不稳定。原因在于单对话是线性生长的模型不会像真人写手那样写完第三章突然意识到第一章的框架有问题翻回去重写。它只会顺着当前内容继续往下编除非你在某个节点主动打断并让它修正否则错误会一路带着走。一旦任务复杂度超过某个阈值加强提示词的收益会急速递减。多智能体系统解决的是这个结构性问题。它把任务从一条线变成了一个流程每个智能体只处理自己分工内的一小段产出物通过固定格式交接给下一个环节下一个环节发现问题可以驳回上一环节类似真实公司里的打回修改。这等于给大模型加了一个组织结构的骨架让每次调用都在可控的上下文中进行而不是无限累积。当初我尝试设计多角色流程时是因为看到团队里有位同事用流水线方式处理机械设计参数核对效果很稳。每步只让模型做单一职责的事输出用于下一环的作业。我受启发才把内容协作的场景也按这套逻辑搭起来——这就是开头说的 agency-agents 的雏形。1.3 什么任务值得上多智能体多智能体不是万能药它也有协调成本和 token 消耗。根据我的经验满足以下任一条件的任务值得考虑这套方案多源信息收集需要从不同来源抓取资料、交叉验证、汇总成结构化信息单一模型容易把来源混在一起。多轮修改迭代产出需要经过写稿、审校、修改、再审校的循环单一对话改几轮就乱了。分模块交付最终交付物本身包含多个独立模块每个模块可以由独立角色并行生产。交叉校验内容涉及大量数据、引用、逻辑推导需要另一个角色来独立检查而不是让写作者自己检查自己。反过来说如果任务只是帮我把这段文字润色一下或者写一篇一千字的短文案直接用单次对话就够了。我见过有人把三句话的摘要也套上五六个智能体纯属浪费 token。判断标准很简单任务的输出是否可以被拆成至少三个有明确边界、互相依赖的子产物。拆不开就别上多智能体。2. 把团队拆成角色agency-agents 的职能架构设计确定了要多角色协作下一步就是设计这套数字代理机构的岗位。我在最初版本里设计过七八个角色后来发现四五个就够用角色太多协调成本反而高于收益。下面是我最后沉淀下来的一套最小可用职能架构。2.1 最小可用的角色清单与职责边界我把整个系统控制在四个核心角色外加一个可选的审计员角色核心职责可用工具主要产出物禁止事项主管/规划员拆解任务、分配资源、判断验收任务板、需求文档、日程工具作业单、验收标准、任务调度不直接写内容、不做资料检索研究员收集资料、筛选事实、提取要点搜索引擎、知识库、文档读取事实卡片含来源和置信度不生成最终文案、不做主观评价写作者基于事实卡片和作业单完成内容起草文本生成、模板引擎、知识库草稿、章节内容、存疑标记不自行补充未经研究员确认的数据编辑/质检员复核内容质量、校验逻辑、对照需求查漏文本比对工具、评分模板、需求文档质检报告、修改建议、驳回/通过结论不直接重写内容只提问题这四个角色形成了一个最基础的代理机构闭环主管拆活 → 研究员找料 → 写作者出稿 → 质检员把关。如果对应到传统内容代理公司就是项目经理、调研部、创意部、编辑部的缩减版。当初设计职责边界的时候我踩过一个特别典型的坑一开始让研究员顺手写一小段内容概述结果它越写越多最后直接输出了完整章节导致写作者拿到的不是事实卡片而是半成品两边工作重复。后来我在每个角色的指令里都加了明确的禁止事项比如研究员不得生成超过两百字的叙述文本、写作者不得自行补充来源数据才把越界问题止住。2.2 作业单模板把需求写成智能体能懂的结构给智能体派活不能像对同事那样说你大概看一下这个项目帮我整理一下必须给一张结构化的作业单。我常用的模板是这样{ task_id: T2026-0081, assignee: research_agent, target: 整理2025-2026年某智能家居细分市场的规模数据与增长趋势, background: 客户要求报告必须包含最近两年的市场规模估算和增长因子数据源需可追溯, inputs: [ docs/market_data_collection.md, docs/industry_terms_v1.md ], expected_output: fact_cards/bedroom_smart_devices.json, output_format: 每张事实卡片包含key_takeaway、source_url、publish_date、confidence_level、related_tag, quality_requirements: [ 所有数字必须附带来源链接, 置信度低于0.6的信息单独标记为待验证, 总量不超过15张卡片 ], prohibited_actions: [ 不输出超过200字的连续叙述, 不做趋势预测只做现状描述, 不修改输入文件 ] }每个字段都不是随便写的。target 定义目标background 提供语境inputs 指定可读的文件expected_output 规定产物放哪output_format 约束结构quality_requirements 是验收标准prohibited_actions 是底线。特别是prohibited_actions它解决的问题是智能体乐于表现的天性模型天生容易被最近指令带跑你明确写一句不输出超过200字它就大概率不会给你写作文。2.3 树形层级与扁平协作怎么选有人会把多智能体设计成完全互联互通每个角色都能和其他任何角色对话。这个想法很美实际跑起来很容易失控因为对话轮数会呈指数增长。我最终的方案是树形为主、审计旁路主管是第一层负责拆任务、派任务、收结果。研究员和写作者是第二层只跟主管交互不直接互相聊天。编辑/质检员作为旁路环节接收主管转来的成品做检查检查结果回到主管。层级一定要控制在两层以内。超过两层之后传话失真会非常严重——A 告诉 BB 告诉 CC 执行时理解已经变了而且一旦某个中间节点出问题排查链路会拉得很长。树形结构还有一个好处每个角色只需要了解自己的职责和上下级不需要知道整个系统的全貌出错时可以快速定位到节点。如果你处理的业务特别复杂合理的做法也不是增加角色数量而是增加重复的工作组比如同时跑三个研究员负责不同的子领域最终由主管汇总。这个逻辑跟真实公司扩招一个小组是一样的比设计一个全能型的超复杂角色更可靠。3. 协作不靠嘴靠协议任务卡片、状态机与结果回传机制角色定好了接下来是最容易出问题的环节这些智能体之间靠什么协作我最初犯过一个错让两个智能体用自然语言自由对话你把昨天研究的结果发我一下好的我发你能不能再完整一点那我重新整理。听起来很接近真人实际上token烧得飞快而且模型会产生大量无意义的寒暄、确认、重复说明。最离谱的是有一次研究员和写作者聊了三十多轮最后写作者拿到的核心数据竟然还是旧版。从那以后我定了一条铁律智能体之间不聊天只读写结构化消息。3.1 用结构化消息替代自由对话每个任务在流转时都会生成一张任务卡片像工单一样在各个角色之间移动。一个典型的流转卡片长这样{ task_id: T2026-0081, assignee: research_agent, status: in_progress, input_refs: [docs/market_data_collection.md], output_refs: [], trace_log: [ {time: 09:33:01, event: task_received, detail: from_planner}, {time: 09:33:20, event: tool_call, detail: web_search: 智能家居市场规模 2025}, {time: 09:41:05, event: artifact_written, detail: fact_cards/bedroom_smart_devices.json} ] }所有关键信息都在卡片里谁处理过、用了什么工具、产出了什么文件、什么时候处理的。这些数据会被写到共享任务板里而不是通过对话历史来回传递。我选择共享任务板而不是消息队列原因很简单任务板天然具备事后审计能力。如果某个环节出了问题我可以直接翻卡片 trace_log 看完整轨迹不需要从一大堆聊天记录里拼凑真相。消息队列传递的是状态变化但状态变化不等于完整日志出了问题还是得回去找原文。3.2 状态机避免重复执行与跳过质检没有状态的协作系统会出现两个典型的灾难性场景。场景一研究员完成了检索但因为系统没有标记已完成又自动执行了一遍白白烧掉两倍 token。场景二写作者交稿后编辑还没有检查系统就因为某种误判直接标记全部完成把有问题的稿子送到了用户面前。我后来引入了一套简单的状态机所有任务卡片只能在以下五个状态之间流转待处理pending主管已创建任务尚未派发。进行中in_progress对应角色已领取任务正在执行。待复核review_pending产出入库等待编辑/质检员检查。已完成done质检通过主管确认归档。已驳回rejected质检不通过退回原执行角色。状态转换规则必须写死只有待处理可以进入进行中防止重复领取。只有进行中可以进入待复核确保没有跳过执行环节直接质检。只有待复核可以进入已完成或已驳回防止绕过质检。已驳回必须重新进入待处理由主管重新派发或调整作业单。这套状态机逻辑虽然简单但它是整个系统稳定运行的底座。你可以用任意语言实现本质上就是一个条件判断表在驱动。后来我在一个自动化流程平台里用可视化的方式重新搭过一遍逻辑完全一样只是从代码换成了界面拖拽。3.3 结果回传与上下文裁剪回传机制是另一个容易被低估的细节。一个研究员在处理检索任务时模型内部会产生大量中间过程——思考、临时查询、分析、改写——但这些过程绝不应该全部传给下一个角色。否则写作者拿到手的是一大堆混乱的中间信息而不是干净的事实卡片。在实际项目中我要求每个角色执行完任务后只回传三样东西最终产物文件路径、变更摘要、遗留问题清单。变更摘要控制在三百字以内只写我完成了什么、关键结论是什么、有什么需要注意的遗留问题单独列出供主管决定是继续追加任务还是人工介入。这样做最大的好处是上下文裁剪。下一个角色打开任务卡片时看到的是高度浓缩的产物和摘要而不是几十轮对话记录。我实测过采用这种方式之后后续角色的有效指令遵循率明显提高因为它的上下文窗口里几乎没有噪音。如果你也在搭建类似系统建议一开始就把上下文裁剪当作硬性需求写进架构而不是事后再补。事后补裁剪技术难度不大但是数据已经污染过一轮清洗成本高得多。4. 给智能体装上手和眼睛工具调用与知识来源接入一个只有嘴没有手的智能体是干不了活的。研究员需要搜索引擎写作者需要文档读取质检员需要文本比对工具。工具接入这块核心不在于怎么调用 API而在于如何让模型在正确的时机、用正确的方式调用正确的工具。4.1 工具注册表让模型理解能干什么我在落地时没有直接用那种把所有工具都塞给所有角色的方式而是建了一个工具注册表并给每个工具写清楚描述。下面是一个搜索引擎工具的定义示例{ name: web_search, description: 通过搜索引擎查询公开网页信息。当需要获取最新数据、第三方报告、新闻动态时使用。返回结果为带标题、摘要、URL的条目列表。, parameters: { query: 字符串建议包含明确领域词和时间范围, max_results: 整数默认10最大30, freshness: 可选2025-01-01:2025-12-31格式的时间筛选 }, return_schema: [ {title: str, abstract: str, url: str, publish_date: str} ] }很多人会忽略 description 的力量。模型的工具调用能力非常依赖 description 写得是否清晰。比如我只写网页搜索模型在不确定的时候就会反复调用我写清楚当需要获取最新数据、第三方报告、新闻动态时使用模型就会更精准地触发它。description 里还可以加否定条件比如不要用此工具查询固定公式或法律法规条文应使用知识库工具能有效减少误调用。4.2 按角色授权防止越权操作工具不是越多越好。给每个角色配工具我的原则是能用最少的工具完成任务就绝不多给。少一个工具就少一类幻觉来源也少一分被恶意提示注入的风险。在我现在的系统里主管/规划员任务板、需求文档读取、日程工具。它不需要搜索因为它是拆活的人不是找料的人。研究员搜索引擎、知识库检索、网页内容解析、PDF读取。它不需要写文件到最终交付目录。写作者知识库检索只读、文档生成模板、格式化工具。它没有搜索引擎权限起码要保证写作者必须基于研究员给的事实卡片来写这个约束很难被绕过。编辑/质检员文档比对、需求文档读取、格式校验、引用链接检查。它没有搜索新资料的权限避免它用搜索重新生产内容。授权粒度可以更细比如研究员搜索时可以用哪些域名白名单、写作者能否读取某个目录之外的文档、质检员的校验工具是否需要人工审批。先按角色-工具的粗粒度搭起来再根据实际需求加条件比一开始就搞最低权限委员会要高效。4.3 成本与安全边界接入工具之后成本控制就成了重点尤其是搜索引擎和文档解析这两类外部服务调用一次就是一笔费用。我在系统里给每个任务设置了硬性限额单任务检索次数上限20次单条网络请求超时10秒单任务最大并发请求3个每个角色单任务 token 预算研究员 80k、写作者 100k、质检员 60k这些数字不是拍脑袋定的是跑了十几个任务之后统计出来的经验值。预算设置得太低研究质量会打折扣设置得太高一次失控循环就烧掉大几百块的 token 费用。安全边界同样重要。网络请求必须走白名单域名尤其严禁请求可疑的外链和下载未知文件任何改变系统状态的操作——写文件、发通知、调外部接口——都必须在 trace 里留痕关键操作要经过人工确认。我见过一个项目就是因为没有加白名单智能体在检索时被某个页面里的恶意提示词说服然后试图调用内部接口幸好下层有个管理员审批兜底才没出事。5. 完整跑一遍流程某行业分析报告的实际产出链路讲了这么多架构和机制可能还是有点抽象。这一节我拿一个实际跑过的项目作为案例为某个科技园区撰写一份某智能家居细分领域的发展趋势分析报告。整个过程从主管拆解任务开始到人工复核结束大约两小时产出初稿四十分钟复核完成。下面按时间顺序拆一遍。5.1 主管agent的任务拆解主管拿到需求文档后先对照报告大纲拆出六个子任务子任务编号任务名负责角色主要输入输出要求S-01拆解行业定义与分类研究员需求文档、术语表事实卡片集A10张S-02收集市场规模与增长数据研究员需求文档、数据源清单事实卡片集B15张S-03整理核心技术路线研究员行业资料包事实卡片集C12张S-04起草第一章至第三章写作者事实卡片A/B/C报告初稿前三个章节S-05起草第四章至第六章写作者事实卡片B/C 待验证清单报告初稿后三个章节S-06全稿质检并输出修改建议质检员全文初稿、需求文档质检报告、修改建议清单主管不直接干活它只是创建这些作业单并分配给对应角色同时给每个子任务设定优先级和依赖关系。S-04 依赖 S-01/S-02/S-03 完成S-06 依赖 S-04/S-05 完成。在任务板上这些依赖关系会显示为前置条件研究员没交卡片之前写作者的作业单不会变为待处理。5.2 研究员agent的检索与沉淀研究员收到作业单后先读取输入文件然后按关键词分批执行搜索。比如它搜索智能家居市场规模 2025拿到第一批结果后会用网页解析器读取正文内容提取关键段落生成一张事实卡片。一个典型的卡片长这样{ id: FC-B-07, key_takeaway: 预计到2026年某细分智能家居品类年出货量将达到4200万台年增速约18%, source_url: https://example-report.example/2025/market-report, publish_date: 2025-06-15, confidence_level: 0.78, related_tags: [market_size, home_smart_devices], notes: 该数据由行业机构估算统计口径包含线上和线下渠道 }研究员会特别注意 source_url 和 publish_date 的完整性。没有来源的数据宁可不要。置信度低于 0.6 的信息它会单独标记为待验证不会混进高置信度卡片。这避免了写作者拿到混合可信度信息后把传闻当成事实写进正文。5.3 写作者与审计员的接力过程事实卡片到齐后主管把卡片集和需求文档打包给写作者。写作者按照报告大纲逐章生成内容每写一个章节它会把用到的卡片ID记录在文档末尾的引用列表里。这样最终交付时可以直接从引用列表回溯到每一段内容的来源。写作者遇到卡片数据不足或者互相矛盾的情况不会自己脑补而是会留下存疑标记例如[存疑] 增速数据在卡片FC-B-0718%和FC-B-1115%之间存在冲突需二次确认。存疑标记非常重要它把模型不确定显式暴露出来而不是藏进正文。质检员拿到初稿后会对照需求文档逐项检查。它输出的质检报告包括五部分需求吻合度、事实一致性、逻辑连贯性、引用可追溯性、格式规范性。每一部分给出通过/驳回/存疑的结论并附上修改建议。在我这次运行中质检员提了两个问题一是第三章有一处引用了年出货量突破一亿台的说法与事实卡片数据不符二是第五章缺少对可能影响市场规模落地的不确定因素的分析。两个问题都被标记到修改清单里交由写作者二次修订。5.4 人工复核与最终交付质检通过后报告并不会直接发出去。出于行业习惯和风险考虑我还是保留了人工复核环节。复核时我重点看了三部分所有涉及具体数字的段落是否与来源一致、存疑标记是否已经解决、报告结论是否超出事实卡片所能支持的范围。确认无误后把最终版本归档交付。这次流程的完整交付物包括正文报告、来源引用列表、待验证信息清单、质检记录、人工复核记录。五份文件打包发给客户对方看后反馈了三条修改意见全部落在措辞层面没有事实层面的硬伤。这是单模型对话很难达到的效果——因为它很难在一份长报告里同时保证引用可追溯、逻辑一致和需求吻合。6. 踩坑实录上下文污染、任务漂移和幻觉的排查链路再稳定的流程第一次跑的时候也会踩坑。这里把我在实际运行中遇过的三个比较有代表性的问题完整复盘一下排查过程比结论更值得看。6.1 任务漂移调研agent写起总结来了第一个遇到的问题发生在一次市场信息收集任务里。研究员跑着跑着产出物开始变形预期是结构化事实卡片但任务板上出现了一大段一大段带标题的总结文字。第一份还能看出是资料概述第三份开始直接出现综上所述这类结论性文字这明显已经不是研究员该干的活了。我当时没有直接改 prompt而是先查 trace。trace 里显示研究员在某个时间点调用了网页内容解析工具把整篇报告全文读入随后它的输出格式就逐渐偏离了卡片模板。根因是研究员在执行过程中读完一篇长文后模型在全文总结这个偏向目的驱动下把中间产物也写成了总结。我调整了两处一是在作业单的 output_format 里加强了对 JSON 结构的强制说明二是给研究员加了禁止输出超过200字的连续叙述这一条禁令。改完重跑卡片输出恢复正常。这类问题的通用修复思路是不跟模型讲道理给它一个强烈的结构约束。自由文本格式越开放模型发挥空间越大越容易漂移。6.2 上下文污染编辑引用了旧版本已删除的数据第二个问题更隐蔽。一次报告复审时质检员在修改建议中引用了一组数据但那组数据在最新版初稿里已经被删掉了。如果人工没注意这个旧数据差一点被重新加进终稿。通过 trace 发现问题出在回传机制上。当时我把写作者的全部上下文记录直接打包传给了质检员质检员的模型没有区分最终稿和历史讨论片段它从历史片段里抓到了那组旧数据。修复方案就是前面提到的上下文裁剪质检员只接收最新版正文、变更摘要、需求文档和事实卡片不接收任何中间轮次的历史记录。这个改动之后这类问题再没出现过。这里要特别说一下上下文污染在长流程里几乎是必然发生的不是你写 prompt 技巧够好就能避免。唯一可靠的办法是控制传入内容边界从机制上隔离历史和当前。6.3 幻觉型引用参考文献出现不存在的链接第三个问题是幻觉型引用。报告中某处标注了一个来源 URL看起来格式完全正常但我点进去发现是 404。这不是研究员编数据而是后续环节的模型在引用卡片时把卡片里本来正确的 URL 记忆错了一部分生成了一个相似的假链接。排查链路走得比较快因为引用 URL 都是随卡片传递的我只需要对比最终稿里的 URL 和事实卡片里的 URL 就能定位是哪一步产生的差异。结果是写作者在把资料转述成正文时手滑重组了链接。修复方式是在质检环节加入一个引用校验工具自动提取正文中的所有外链逐一发送 HTTP 请求验证状态码不是 200 或 403 的链接全部标记为待确认。这个工具花了半小时写但从此解决了引用链接烂尾的问题。如果你也做内容类项目强烈建议把这个校验放到质检里成本极低、收益明显。6.4 通用排查五步法这三类问题看起来各不相同但我事后总结排查路径高度一致分享一个通用五步法固定输入。用同一份需求、同一份资料、同一个模型版本重跑一次先确认问题是稳定复现还是偶发。清理上下文。把任务板里可能残留的旧版本数据先隔离切断跨任务的上下文影响。翻 trace。看问题角色在问题发生附近的工具调用序列和输入内容多数情况问题就藏在某一次调用的入参里。审查结构约束。检查作业单的 output_format、prohibited_actions、回传机制是否足够严格不够严格就加不要指望模型自律。回归验证。修改后重跑同一任务并额外加一个反向验证主动投喂一份故意有错的输入确认系统能拦得住。这套五步法我用到现在没有一次排查超过两个小时。核心心态是先把系统可能出错的地方当成系统设计问题而不是模型能力问题这样才会去加固结构而不是反复调 prompt 碰运气。7. 质量兜底审计员agent与人工复核的双保险内容行业的命门是质量。前面提到的质检员角色其实已经承担了一部分质量检查但在实际落地时我还额外加了一道审计员环节两道防线叠加才敢把产出物对外交付。7.1 审计员agent如何工作质检员检查的是稿件是否满足需求和内容是否自洽审计员检查的则是整条生产链路是否可信。在我的系统里审计员不负责具体内容的审查它读的是所有任务卡片、trace 日志、工具调用记录、质检报告然后输出一份流程审计报告。审计维度包括引用可追溯性每个关键数据是否都能从事实卡片回溯到原始来源。数据一致性是否存在同一数据在不同章节数值不一致的情况。检查覆盖度每个子任务是否都经过了质检环节是否有跳过质检的环节。风险提示完整性报告中是否覆盖了可能影响结论的不确定性因素。格式规范性是否满足交付模板要求。这个角色相当于代理机构里的客户总监它关心的不是某一句写得好不好而是整体流程有没有漏洞。比如有一次审计员发现某个子任务的状态机记录显示直接从进行中跳到了已完成这违反了我们定死的转换规则。经过排查是当时的自动化流程平台里一个条件分支写错了。如果没有审计员这层复查这种系统级 bug 很可能就带着不合规的流程混过去了。7.2 人工必须接管的几种情况智能体再强也不能完全替代人的判断。我给自己定了一条铁律以下情况必须有人工复核任何自动化流程都不能代替对外发布内容会影响到外界判断的内容必须人工把关。含有具体数字结论特别是市场数据、财务数据、技术参数人类要对数字承担最终责任。涉及第三方权益引用他人报告、文章、图片时人工确认使用范围和标注。自动化流程异常后的恢复发生过状态异常、驳回、重跑的任务在归档前必须人工检查。人工复核清单我直接写进了项目SOP里每次交付前照着打钩不勾完不归档。这不是形式主义而是出过一次事后形成的习惯有一次报告里引用了竞品厂家的一组技术参数来源是行业报道但后来发现该数据已经被厂家官方辟谣。自动化系统只检查了来源存在根本没有能力判断来源可信度。从那以后来源可信度由人工兜底不交给任何模型。7.3 持续回灌把问题固化成规则最后一步是把发现的问题回灌到系统规则里形成一个持续改进的闭环。具体做法是审计员每次发现问题后会录入一个错误库内容包括问题描述、发生环节、根因、修复方案。每隔一段时间我会把错误库里的高频问题整理成新的禁止事项和质检规则更新到主管的作业单模板里。举例来说第一版系统里没有禁止研究员输出扫描表格文案这条规则因为当时没遇到过后来某次研究员把网页里的表格整段复制进卡片导致写作者误用这个案例进错误库规则库里就多了这一条。三个月跑下来错误库积累了二十多条规则常见问题出现的频率明显下降了。这套闭环机制的价值在于系统不是越用越差而是越用越聪明。如果你搭了多智能体系统但没有做规则回灌那每一次踩坑都只是单次修复系统本身没有成长做了回灌每踩一次坑后续所有任务都会受益。最后聊一点个人体会。真在项目里把 agency-agents 用起来之后我最大的感悟是把智能体当实习生带而不是当神仙供着。你给的作业单越具体、验收标准越前置、禁止事项越明确产出就越接近预期。不要追求全自动关键节点保留人工审批成本不高但安全感拉满。如果让我重来一次我会在搭建第一天就先写好整套验收标准而不是边跑边补——前两周省下的那一堆返工时间够我多跑好几个项目了。