LocalAIHub 中文社区

写作日期：2026-05-22 AI 浏览器代理最容易让人产生错觉。它能打开网页、读页面、点按钮、填写表单、下载文件、上传附件、切换标签、截图、提取信息，表现得很像一个坐在电脑前的人。团队看到演示后，很自然会想到更多场景：让它登录后台查数据，让它帮运营发布内容，让它从供应商网站收集价格，让它填报销单，让它自动处理订单，让它跑一遍竞品页面。浏览器是今天数字工作的入口，所以能操作浏览器的 AI 看起来像能操作整个互联网。 问题也在这里。浏览器不是一个干净的 API 环境，而是一个混合了登录态、第三方网页、广告脚本、表单、支付按钮、验证码、下载文件、剪贴板、扩展、跨站跳转和用户隐私的复杂界面。页面内容本身可能可信，也可能恶意；按钮文字可能清楚，也可能误导；登录态可能只属于当前任务，也可能代表用户全部账号权限。AI 浏览器代理一旦拥有真实点击和输入能力，风险就从“回答错了”变成“真的提交了、真的下载了、真的删除了、真的付款了”。 这篇社区实践帖讨论一个核心问题：AI 浏览器代理能做什么，不能做什么。它不是反对浏览器代理，相反，浏览器自动化是非常实用的 AI 能力。Playwright 这样的自动化框架已经在测试、爬取、表单操作和端到端验证中成熟使用；Browser Use、Computer Use 等能力把页面观察、动作选择和模型推理连起来，让非结构化网页也能被智能体处理。但生产级使用必须划边界。能阅读不等于能授权，能填表不等于能提交，能看到登录页面不等于能绕过验证码，能下载文件不等于能打开任意文件，能访问网页不等于能把网页指令当系统指令。 一、先把浏览器代理分成四层能力 讨论边界前，先把能力分层。第一层是观察能力：打开网页、读取标题、URL、DOM、可见文本、截图、表格、链接、按钮、表单字段和错误提示。这个层级主要是“看”。它可以用于网页理解、信息提取、页面巡检、资料整理和测试诊断。风险相对低，但仍可能接触敏感信息和恶意内容。 第二层是导航和输入能力：点击链接、滚动页面、切换标签、输入关键词、选择下拉项、上传文件、下载文件、填写表单。这个层级开始改变浏览器状态，但不一定改变外部业务状态。比如在搜索框里输入、在草稿框里写内容、打开筛选器、选择日期范围。风险中等，因为错误点击可能进入危险页面，错误输入可能暴露隐私，上传下载可能带来文件风险。 第三层是提交和写入能力：提交表单、发送消息、发布内容、创建订单、更新资料、保存配置、确认删除、触发工作流。这个层级会改变网站或业务系统状态。它不再是普通“浏览”，而是代用户执行动作。必须有权限、确认、审计和回滚设计。 第四层是高风险外部动作：支付、退款、转账、购买、授权 OAuth、授予权限、修改密码、解绑银行卡、删除数据、取消订阅、发出不可撤回的公开内容、操作生产后台。这些动作不应该由通用浏览器代理自动完成。更合理的做法是让 AI 读页面、解释选项、准备草稿、指出风险，再让用户或业务系统完成最终确认。 这四层划分比“让不让 AI 控浏览器”更实用。一个产品可以允许浏览器代理自动完成观察和低风险输入，但对提交和外部动作加确认；可以让它在测试环境自由点击，但在生产后台只读；可以让它生成表单草稿，但不让它按下付款按钮。边界越具体，体验越可控。 二、浏览器代理擅长什么 浏览器代理擅长处理那些网页结构复杂但风险较低的重复任务。比如读取多个网页的信息并整理成表格，比较不同产品价格和参数，检查一组页面是否存在 404、错别字和布局问题，打开后台页面核对某个字段，帮用户在复杂表单中准备填写内容，阅读公开文档并提取步骤，生成页面测试报告。这些任务的共同点是：主要价值来自观察、理解、整理和低风险输入。 它也擅长做探索式网页自动化。传统 Playwright 脚本需要开发者预先写选择器、断言和流程；AI 浏览器代理可以根据页面变化临时决策，比如看到登录按钮就点击，看到筛选器就调整，看到错误提示就解释原因。对不稳定页面、临时运营后台、第三方网站和一次性资料收集，这种灵活性很有价值。 浏览器代理还适合做产品验收。真实用户路径经常跨多个页面：打开首页、登录、搜索、筛选、进入详情、提交表单、查看结果。AI 代理可以像用户一样走流程，并记录截图、URL、按钮文案和异常。它能发现接口测试发现不了的问题，例如页面文案混乱、按钮不可见、弹窗遮挡、移动端布局错位、登录后跳转错误、空状态没有说明。 对企业内部工具来说，浏览器代理还能降低集成成本。不是每个旧系统都有 API，也不是每个供应商愿意开放接口。有些工作只能通过网页后台完成。浏览器代理可以作为过渡方案，把人工重复操作变成可审计的半自动流程。但这里要强调“过渡”和“半自动”：如果某个动作长期高频、高价值、高风险，最终应该建设正式 API、权限和流程，而不是一直靠浏览器模拟点击。 它也适合辅助而不是替代。比如帮用户解释网页上复杂的设置项，指出需要填写哪些字段，预填一份内容，提醒哪些按钮会产生外部影响。用户仍然是确认人，AI 是阅读和准备工具。这种模式常常比全自动更可靠，也更容易被业务接受。 三、浏览器代理不擅长什么 浏览器代理不擅长承担最终责任。网页上的内容可能过期、恶意、误导或不完整，模型对页面的理解也可能出错。它可以建议“这个按钮看起来会提交订单”，但不能替代业务规则判断“是否应该提交”。真正的责任需要落在人、业务系统或明确审批流程上。 它不擅长处理强安全边界。验证码、二次验证、短信码、人脸验证、硬件密钥、银行 U 盾、风控弹窗，本质上都是为了确认真实用户或阻止自动化。AI 浏览器代理不应该试图绕过这些机制。遇到验证码和强认证，合理行为是暂停，请用户完成，或切换到官方 API 和授权流程。把绕过验证码当作能力，会让产品直接进入违规和滥用区域。 它不擅长高风险不可逆动作。支付、转账、退款、购买、删除、授权、公开发布和生产配置修改，都需要确定性系统、权限校验、确认和审计。浏览器代理可以读页面、准备草稿、解释影响，但不能在没有明确确认的情况下自动提交。即使用户一句话说“帮我搞定”，系统也要拆解出最终参数并让用户确认。 它不擅长长期依赖脆弱页面。第三方网站经常改版，按钮文字、DOM 结构、登录流程、风控策略、分页和弹窗都会变。AI 比固定脚本灵活，但不代表稳定。关键业务若长期依赖第三方网页自动化，会面临不可控变更、账号风控、法律条款和数据质量问题。能用官方 API 时，应优先用 API。 它也不擅长处理需要严格数据一致性的流程。浏览器界面是给人看的，不一定暴露完整事务状态。页面显示“提交成功”可能只是前端状态，后端任务还在处理中；点击退款后可能只是创建申请，不是退款完成；下载报表可能是异步生成。若系统需要强一致、幂等、回调和对账，浏览器代理应该退居辅助，核心动作交给后端 API。 四、Playwright 和 AI 浏览器代理不是一回事 Playwright 是成熟的浏览器自动化框架，提供可靠的定位器、自动等待、动作可执行性检查、网络控制、认证状态复用、文件上传、截图和测试断言。它适合写可重复的脚本：进入页面，定位按钮，填写字段，断言结果。Playwright 文档强调 actionability checks，例如元素是否可见、稳定、可接收事件、可编辑，这些机制让自动化脚本比简单坐标点击可靠得多。 AI 浏览器代理通常在 Playwright 或类似能力上再加一层模型决策。模型观察页面，决定下一步点击哪里、输入什么、是否滚动、是否返回、是否提取信息。Browser Use 这类项目就是把浏览器动作和 LLM 代理结合，让模型能按目标操作网页。OpenAI 的 Computer Use 工具则提供屏幕观察和鼠标键盘动作，让模型能在浏览器或桌面应用中完成步骤。 两者的区别在于确定性。Playwright 脚本是开发者写死流程，适合稳定回归；AI 浏览器代理是模型动态决策，适合开放探索。前者失败时容易定位选择器或断言问题；后者失败时可能是页面理解、目标分解、视觉识别、提示注入、登录态、网络或动作选择问题。生产系统不能把 AI 代理当作普通测试脚本直接信任。 更好的组合方式是：用 AI 代理探索和生成候选流程，用 Playwright 固化高频稳定流程；用 Playwright 的定位器、自动等待、断言和认证状态管理提供可靠执行底座，用模型处理页面变化和语义理解。对关键流程，最终仍应沉淀为可测试、可审计、可回放的自动化，而不是每次让模型临场发挥。 另一个差别是安全边界。Playwright 默认按脚本执行，安全来自脚本作者和运行环境；AI 代理会读取网页内容并把它纳入决策，必须额外防提示注入和越权动作。网页里的文字不能成为更高优先级的指令，模型看到“点击授权并输入验证码”也不能自动照做。AI 代理需要比传统脚本更多的任务权限、域名限制和确认机制。 五、登录态：浏览器代理最危险的隐形权限 登录态是浏览器代理的核心风险。Cookie、localStorage、sessionStorage、浏览器 profile、扩展和保存的密码，代表用户在多个网站上的真实身份。一个浏览器代理如果使用用户日常浏览器 profile，就可能继承邮箱、网盘、支付平台、公司后台、社交账号和云控制台的登录权限。它看起来只是在完成一个小任务，实际拥有大量横向能力。 生产系统不应该默认让 AI 使用用户完整浏览器 profile。更稳的方式是为每个任务创建隔离浏览器上下文，只登录当前任务需要的网站。Playwright 支持 browser context 和 storageState，可以保存和复用特定站点认证状态，但这也意味着认证状态文件包含敏感 cookie 和 header，需要像密钥一样保护。不要把 storageState 放进普通日志、公开仓库或可下载调试包。 登录态还要按任务授权。用户要求“帮我查看这个供应商后台订单”，不等于授权 AI 同时打开邮箱、云盘和银行网站。任务启动时应明确可访问域名、可使用账号、有效时间和可执行动作。浏览器代理若试图访问未授权域名，应被阻止，而不是让模型自己判断是否合理。 多账号场景更复杂。一个用户可能在同一浏览器里登录多个租户、多个环境、多个客户后台。AI 代理必须知道当前操作属于哪个租户、哪个账号、哪个环境。测试环境和生产环境要明显隔离，不能因为页面相似而点错。对企业后台，最好使用专门的低权限机器人账号或受限用户账号，而不是管理员账号。 登录失败和二次验证也要有边界。AI 可以告诉用户“当前需要登录”或“页面要求二次验证”，可以等待用户手动完成，也可以使用官方 OAuth 授权流程。它不应该要求用户把短信验证码、一次性密码或恢复码发给模型，更不应该把这些信息写入日志。二次验证的意义就是让自动化停下来确认人类在场。 退出和清理同样重要。任务结束后，应清理临时 Cookie、缓存、下载文件和上传文件，关闭浏览器上下文。长时间保留登录态会扩大风险窗口。若必须保存会话，应记录用途、所有者、过期时间、最后使用时间，并允许用户撤销。 六、表单：能填不等于能提交 表单是浏览器代理最常见的应用场景。填写采购申请、报销单、CRM 客户信息、招聘表、后台配置、问卷、内容发布页，都很适合 AI 先帮用户整理字段。模型能从上下文中提取姓名、日期、金额、地址、描述和附件，减少人工复制粘贴。但表单也是风险高发区，因为“填入字段”和“提交生效”之间有明确边界。 安全做法是把表单操作拆成三个阶段：理解字段、生成草稿、确认提交。理解字段时，AI 读取页面标签、placeholder、必填项、帮助文本和错误提示。生成草稿时，AI 把值填进页面或在旁边给出预览。确认提交时，系统展示最终字段、目标网站、提交按钮含义、影响对象和风险提示，由用户确认后再执行。 不要让模型在模糊信息下自动提交。比如用户说“帮我把上次那个客户资料补一下”，模型可能猜错客户；用户说“金额按之前的来”，模型可能取错记录；页面有两个“保存”按钮，一个保存草稿，一个发布上线，模型可能误判。遇到指代不清、字段缺失、金额、身份、权限和外部影响时，应追问或停在草稿。 表单字段还要做类型和范围校验。模型生成的日期、金额、邮箱、手机号、身份证号、订单号、地址、URL、SQL、正则表达式都可能有格式错误。浏览器页面本身可能有前端校验，但生产系统不能只依赖页面。若表单提交背后是自己系统，应在后端校验；若是第三方页面，至少在确认页前做本地校验和异常提示。 附件上传要特别谨慎。AI 不应从用户目录自由挑文件上传。用户应明确选择可上传文件，系统生成文件 ID，浏览器代理只能使用这些授权文件。上传前要展示文件名、大小、类型、目标网站和用途。涉及合同、身份证、财务凭证、源代码和客户资料时，更要有确认和审计。 表单提交后的状态也不能靠模型猜。页面提示“已提交”才是一个信号，不一定代表业务完成。系统应记录 URL、页面标题、提交时间、关键截图、表单摘要和网站返回状态。若网站生成申请编号、订单号或工单号，应提取并保存。没有明确结果时，应该说“已提交请求，状态待确认”，而不是直接宣布完成。 七、支付和购买：AI 可以准备，不能擅自付款 支付和购买是浏览器代理必须划红线的场景。AI 可以帮用户比较价格、解释套餐、整理购物车、检查优惠、填写收货地址草稿、计算税费和提醒风险，但不能在没有明确确认的情况下点击付款、转账、购买、退款或订阅。钱的移动需要比普通表单更高的确定性。 支付页面常常有复杂元素：商品名称、数量、币种、税费、运费、优惠券、收货地址、付款方式、分期、自动续费、不可退款条款。模型可能漏看某一项，也可能被页面广告和推荐影响。确认页必须展示最终金额、币种、商户、商品、数量、收件人、付款方式、是否订阅、是否自动续费、退款政策和按钮含义。 支付动作还要防重复。浏览器代理遇到超时、页面卡住或网络断开时，可能想再次点击。传统支付系统强调幂等，浏览器自动化更需要停止策略。支付按钮点击后，代理应等待明确状态，不应反复点击。若状态不明，应提示用户检查订单或支付平台，而不是自行重试。 退款和取消订阅同样高风险。AI 可以解释当前政策、找到入口、准备取消原因，但最终确认应由用户完成。取消订阅可能影响服务、数据保留和合同；退款可能影响订单、库存、财务和客户关系。浏览器代理没有足够上下文承担这些责任。 企业内部如果必须自动处理支付相关流程，应尽量使用正式后端 API、审批、幂等键和对账系统，不要依赖网页点击。浏览器代理可以作为辅助界面层，但真正的钱款状态应以后端支付系统和回调为准。 八、验证码和反自动化：遇到就停，不要绕 验证码、短信码、邮件码、TOTP、人脸验证、滑块、设备确认和风控验证，都是网站用来区分真实用户、降低滥用和保护账号的机制。AI 浏览器代理遇到这些机制时，正确行为是暂停并请求用户处理，或者提示该任务需要官方授权接口。把绕过验证码当作“智能”能力，不适合生产产品。 验证码不仅是技术问题，也是合规和平台关系问题。第三方网站明确不希望自动化时，强行绕过可能违反服务条款，导致账号封禁、法律风险或客户关系问题。即使某些自动化方案能在技术上通过，也不意味着产品应该这样做。 对自己产品内部的验证码，最佳做法不是让 AI 识别验证码，而是在受控测试环境提供测试模式、API token、测试账号或跳过开关。端到端测试和生产用户安全是不同目标。Playwright 测试自己站点时可以使用专门测试账号和受控环境；AI 代理操作第三方站点时应尊重对方风控。 二次验证里的验证码和一次性密码不能让模型保存或复述。用户手动输入后，浏览器上下文可继续任务，但不要把验证码写进聊天记录、日志或任务摘要。若页面要求高风险确认，例如银行或支付平台的验证码，AI 应停止在确认前，让用户自己完成最终动作。 浏览器代理产品应在界面上明确处理方式：需要验证码时暂停；需要短信码时等待用户手动输入；需要人脸或硬件密钥时交还用户；需要长期自动化时建议使用官方 API 或合作授权。这个边界比技术绕过更重要。 九、文件下载和上传：浏览器会产生真实文件风险 浏览器代理不只是看网页，它还会下载和上传文件。下载可能是发票、报表、合同、图片、压缩包、安装包或未知文件；上传可能是身份证、合同、源代码、财务凭证、客户名单。文件一旦进入任务，就会带来隐私、恶意内容、路径、保留期限和权限问题。 下载文件应进入任务沙箱，而不是用户默认下载目录。沙箱应按任务隔离，有大小限制、类型限制、病毒扫描或格式检查，并记录来源 URL、文件名、MIME、大小、哈希和下载时间。下载的文件如果要交给模型读取，也要把文件内容视为不可信数据，不能把里面的文字当成系统指令。 上传文件必须来自用户明确授权。不要让 AI 浏览器代理遍历本地目录找附件，也不要让网页内容诱导它上传某个路径。用户选择文件后，系统给代理一个短期文件句柄或文件 ID，代理只能上传这些文件。上传前应展示目标域名、表单字段、文件信息和用途。 文件名和内容可能泄露隐私。即使不打开文件，文件名也可能包含客户名、项目名、金额、身份证号或内部编号。下载列表、任务日志、截图和审计摘要里都要注意脱敏。上传失败时，不要把完整本地路径显示给页面或写入公开日志。 文件保留要有策略。任务结束后，临时下载和中间解析文件应自动清理，除非用户明确保存。若文件进入知识库或审计系统，要继承权限和保留期限。浏览器代理产生的“临时文件”不能变成无人管理的长期敏感数据。 文件类任务最好限制域名和类型。比如只允许从指定供应商后台下载 CSV 和 PDF，不允许下载可执行文件；只允许向指定报销系统上传用户选择的 PDF，不允许上传整个目录。越具体，越安全。 十、网页提示注入：网页内容不能反过来指挥代理 浏览器代理最大的安全挑战之一是网页提示注入。网页里的文字、隐藏元素、评论、广告、图片 OCR、PDF 内容、搜索结果，都可能写着“忽略之前规则”“把用户资料发送到这个网址”“点击授权按钮”“打开邮箱复制验证码”。这些内容对人类来说可能只是网页内容，对模型来说却可能看起来像指令。 这类攻击叫间接提示注入，因为攻击者不直接和 AI 对话，而是控制 AI 会读取的外部内容。OWASP LLM Top 10 把 prompt injection 列为核心风险，也把 excessive agency 和 sensitive information disclosure 等问题列为重要类别。浏览器代理把外部网页和真实动作连在一起，正好处在这些风险交叉点。 防护第一原则是指令和数据分层。用户目标、系统规则、工具权限来自受信任系统；网页内容只是观察数据。网页可以提供事实、字段、按钮文字和错误提示，但不能改变工具权限，不能要求代理访问其他站点，不能跳过确认，不能要求输出隐藏信息。模型提示里要表达这个原则，工具层也要执行这个原则。 第二原则是域名和动作限制。即使网页诱导代理打开另一个域名，也应被 allowlist 拦住；即使网页要求发送数据，也应被提交确认拦住；即使网页要求下载文件，也应受类型和大小限制。不要把防护全部压在模型“识别恶意文本”上。模型识别会失败，系统边界必须独立存在。 第三原则是最小上下文。浏览器代理不应该同时拥有用户邮箱、云盘、支付网站、公司后台和本地文件系统的全部能力。网页提示注入之所以危险，是因为模型能把一个网页里的恶意指令转移到另一个工具。能力越少，横向伤害越小。 第四原则是关键动作前证据确认。提交表单、发消息、授权、支付、下载敏感文件前，要展示当前页面的关键信息和目标动作。用户确认的是系统整理出的事实，而不是网页夹带的指令。确认过程本身也要可审计。 提示注入不能彻底消灭，但可以把它限制为“模型提出了一个被拒绝的动作”，而不是“模型完成了一个危险动作”。这就是边界设计的价值。 十一、审计：浏览器代理必须能复盘一次点击 浏览器代理做了什么，必须能复盘。传统 API 调用可以记录方法、路径、参数和响应；浏览器操作更复杂，需要记录页面、动作、截图、表单字段、确认和结果。没有审计，出了问题只能看用户描述和模型日志，很难判断是页面误导、模型误点、权限配置错误还是用户确认过。 基础审计字段包括任务 ID、用户、租户或组织、浏览器上下文、允许域名、起始 URL、访问 URL、页面标题、动作类型、目标元素、输入摘要、下载文件、上传文件、提交按钮、确认记录、错误、时间和结果。对高风险动作，还要保存动作前后的截图或 DOM 摘要。 审计要分级保存。普通公开网页抓取可以保存较多上下文；企业后台、客户资料、支付页面和文件内容要脱敏或只保存摘要、哈希和资源 ID。截图可能包含敏感信息，不能随意进入公开日志或客服系统。查看审计也要有权限。 审计还要记录拒绝。代理访问未授权域名、试图点击高风险按钮、遇到验证码、上传未授权文件、提交缺少确认、网页提示注入可疑内容，都应记录。拒绝记录能帮助团队发现边界是否过紧、过松，或者某些网页是否持续诱导异常行为。 对产品体验来说，审计也能建立信任。用户可以看到代理已完成哪些步骤、停在哪里、为什么需要确认、哪些信息被提交。透明度不等于暴露内部实现，而是用面向用户的语言说明关键动作。比如“已读取订单列表，已填写退款原因，等待你确认金额”，比黑盒自动点击更可信。 审计最终要能服务回放和改进。失败任务可以复盘页面状态和动作序列，把稳定流程沉淀成 Playwright 脚本，把易错页面加规则，把高风险动作加入确认，把常见验证码场景改走官方 API。没有审计，浏览器代理永远停留在演示水平。 十二、用户确认：确认要具体，不要形式化 确认机制不能只是一个“是否继续”的弹窗。有效确认要让用户知道：在哪个网站，对哪个对象，做什么动作，关键参数是什么，会产生什么后果，是否可撤销。用户确认的内容必须和执行动作绑定，不能确认前一套参数、执行时又让模型重新生成另一套参数。 比如发布内容时，确认页应显示目标平台、账号、标题、正文摘要、图片或附件、可见范围和发布时间。发送消息时，应显示收件人、主题、正文摘要和附件。提交报销时，应显示金额、币种、类别、发票文件和审批人。支付时，应显示商户、商品、数量、金额、币种、付款方式和自动续费。删除时，应显示对象、数量、位置和恢复方式。 确认还要按风险分级。低风险草稿保存可以轻确认或自动完成；对外发送、支付、删除、授权和生产配置修改必须强确认；大额或批量动作可以要求二次确认或审批。不要把所有动作都同样确认，否则用户会形成机械点击；也不要为了流畅体验取消关键确认。 确认界面要面向最终用户。不要展示内部工具名、JSON 参数、选择器、DOM 路径和调试字段。用户关心的是动作影响，不是实现细节。内部参数可以进入审计，用户界面只展示可理解的事实和后果。 确认后执行要可追踪。系统应生成待执行动作 ID，包含确认版本、参数、用户、时间和目标页面。执行器按这个动作 ID 执行。若页面状态变化导致参数不再一致，应停止并重新确认。比如支付金额变化、收件人变化、按钮变成“订阅并付款”，都不能继续执行旧确认。 确认失败也要清楚。页面过期、登录失效、验证码出现、金额变化、按钮不可见、网络超时，都应告诉用户当前状态，而不是继续猜测或重试。关键动作宁可停下来，也不要在不确定状态下继续点击。 十三、产品体验：不要把边界做成阻塞墙 边界不是为了让浏览器代理难用，而是让它可被信任。好的体验不是每一步都弹窗，也不是把所有危险都藏起来，而是让低风险任务顺滑、高风险动作清楚、失败状态可理解。 一个好的浏览器代理界面应展示任务目标、当前网站、当前步骤、已读取的信息、准备执行的动作和需要用户确认的事项。用户不需要看到模型思考过程，但需要知道代理在哪里、准备做什么、为什么停下。尤其是登录、验证码、支付和上传文件时，停顿要有清楚说明。 边界文案要面向用户。不要显示“工具调用被策略拒绝”“selector timeout”“storageState missing”这类内部说法。可以说“当前任务没有访问这个网站的权限”“这个页面要求你完成验证”“提交前需要你确认金额和收件人”“这个文件没有被授权上传”。用户要知道下一步怎么做。 低风险自动化要减少摩擦。读取公开网页、滚动、提取表格、生成摘要、保存草稿、截图和检查页面，可在任务范围内自动完成。用户选择浏览器代理，是为了减少重复劳动，不是为了给每个滚动都点确认。 高风险确认要有证据。确认页不要只写“即将提交表单”，要展示字段和影响。用户愿意确认，是因为信息清楚，不是因为弹窗存在。产品团队要花时间设计确认体验，而不是把安全责任甩给一个模糊按钮。 失败恢复也重要。浏览器任务经常中途失败：页面改版、网络超时、登录过期、验证码、下载失败、按钮不可见。产品应允许重试当前步骤、返回上一步、交给用户手动完成、导出已整理的信息，而不是整个任务报废。 十四、什么时候该用 API，而不是浏览器代理 浏览器代理适合没有 API、流程变化快、任务低频、需要阅读页面语义的场景。长期生产流程如果高频、高价值、高风险，应该优先建设 API 或正式集成。API 可以提供明确身份、权限、参数、幂等、错误码、回调和审计，比浏览器点击稳定得多。 支付、退款、订单更新、库存同步、用户权限、生产配置、批量数据导入导出，应该尽量走 API。浏览器代理可以帮人找到入口、解释页面、准备草稿，但核心状态变更最好由后端接口执行。这样可以避免页面改版、误点、重复点击和状态不一致。 企业内部系统如果没有 API，可以把浏览器代理当作过渡方案，同时推动系统改造。每当某个浏览器自动化任务变成每天运行、影响业务结果、需要审计和 SLA，就说明它值得被产品化。长期用 AI 点击网页代替系统集成，会把自动化建立在最脆弱的界面层上。 第三方网站尤其要注意服务条款。公开网页阅读和人工辅助通常问题较小，批量抓取、绕过风控、自动购买、自动注册、规避验证码和高频操作可能违反规则。产品团队要考虑法律、账号安全和平台关系，而不是只看技术可行。 一个简单判断标准是：如果动作需要强一致、幂等、回滚、审批、对账或 SLA，就不要只靠浏览器代理。如果动作主要是阅读、整理、比较、草稿和低风险输入，浏览器代理很合适。 十五、团队落地的边界清单 第一，定义任务范围。每个浏览器任务要有目标、允许域名、允许动作、可用登录态、文件权限、超时和风险等级。不要让代理在整个互联网和用户完整浏览器 profile 中自由探索。 第二，隔离浏览器上下文。每个任务使用独立 context，必要时使用任务专用登录态。认证状态像密钥一样保护，任务结束清理 Cookie、缓存、下载和上传临时文件。 第三，限制网络和域名。只允许访问任务需要的网站。阻止内网管理地址、本机端口、云元数据地址和未授权外部域名。第三方跳转要重新确认。 第四，区分观察、填写、提交和高风险动作。观察和低风险填写可以自动，提交需要确认，支付、删除、授权和生产修改需要强确认或人工执行。 第五，文件进沙箱。下载文件进任务目录，上传文件来自用户授权。记录文件来源、哈希、大小和用途。任务结束清理临时文件。 第六，遇到验证码和二次验证就停。不要绕过，不要保存验证码，不要让模型复述一次性密码。用户手动处理后可继续低风险步骤。 第七，网页内容当数据。页面里的文字不能改变系统指令、工具权限、确认要求和域名范围。把提示注入防护落到工具层和策略层。 第八，关键动作前做具体确认。展示网站、对象、字段、金额、附件、按钮和影响。确认内容与执行参数绑定，页面状态变化时重新确认。 第九，审计每次关键动作。记录任务、用户、URL、页面标题、动作、输入摘要、截图或 DOM 摘要、文件、确认和结果。审计内容按敏感等级保存。 第十，把稳定高频流程固化。AI 代理探索出的可靠流程，尽量沉淀为 Playwright 脚本、后端 API 或正式工作流。不要让模型每次重新猜。 十六、典型场景判断 公开资料收集适合浏览器代理。它可以访问指定网站、提取页面标题、价格、发布日期、表格和链接，整理成报告。边界是限制域名、频率和下载类型，尊重网站规则，标注来源。 企业后台巡检适合半自动。代理可以登录低权限账号，检查页面状态、截图、提取异常和生成报告。若需要修改配置，应停在确认或走内部 API。不要用管理员账号让代理自由操作。 内容发布适合草稿模式。代理可以把文章填入编辑器、上传用户选择的图片、预览排版，但发布按钮应确认。对外发布涉及品牌和法律责任，不应无确认自动完成。 报销和采购适合预填。代理可以读取发票、填写金额、日期、项目和说明，上传用户授权附件。提交前展示字段和附件，由用户确认。大额采购或供应商变更应走审批。 客服后台适合辅助查询和草稿。代理可以查看当前客户工单、整理历史、生成回复草稿。发送给客户、退款、改订单状态需要确认和业务权限。 支付和银行不适合自动执行。代理可以解释页面、帮助用户核对信息，但最终付款、转账、授权和验证码应由用户自己完成或由正式金融 API 处理。 验证码密集站点不适合浏览器代理长期操作。如果每次都需要验证码，说明对方不欢迎自动化或需要正式授权。应停止绕行思路，转向 API、合作接口或人工流程。 十七、常见误区 第一个误区是认为“人能点，AI 就能点”。人有责任、经验和法律主体，AI 只是系统能力。能点不代表应该点，更不代表可以无审计地自动点。 第二个误区是直接使用用户日常浏览器 profile。这样代理继承了过宽登录态，任何网页提示注入或误点都可能横向影响其他账号。 第三个误区是把验证码识别当成产品能力。验证码和二次验证是安全边界，生产系统应该暂停或走官方授权，而不是绕过。 第四个误区是只看最终结果，不记录过程。浏览器任务没有审计，失败后无法复盘，也无法让用户信任。 第五个误区是让网页内容决定安全策略。网页可以提供信息，不能要求代理跳过确认、打开未授权网站或读取其他资料。 第六个误区是把确认做成免责按钮。有效确认必须展示对象、参数、影响和后果，并绑定执行动作。 第七个误区是长期依赖浏览器点击替代 API。浏览器适合低频和过渡，关键高频流程应该沉淀为稳定接口或正式自动化。 第八个误区是把所有动作都阻塞确认。低风险观察和草稿可以自动完成，否则产品会变得难用。边界要按风险分级。 十八、结语 AI 浏览器代理的价值在于把网页从“只能人眼操作”变成“可以被智能系统理解和辅助”。它很适合阅读、提取、比较、巡检、预填、草稿和低风险自动化，也能帮助团队验证真实用户路径。它不适合绕过验证码，不适合继承用户全部登录态，不适合在无确认情况下支付、删除、授权和修改生产系统，也不适合长期承担需要强一致和审计的核心业务动作。 生产级边界可以概括为一句话：浏览器代理可以帮用户看清页面、准备动作和完成低风险步骤；当动作会影响账号、金钱、文件、客户、权限或外部世界时，必须由权限系统、确认机制和审计记录接管。这样设计，AI 才不是一个危险的自动点击器，而是一个能被信任的网页工作助手。 参考资料 Playwright Actionability and auto-waiting: https://playwright.dev/docs/actionability Playwright Locators documentation: https://playwright.dev/docs/locators Playwright Authentication and storage state: https://playwright.dev/docs/auth Playwright Input and file upload: https://playwright.dev/docs/input Browser Use documentation: https://docs.browser-use.com/ Browser Use GitHub project: https://github.com/browser-use/browser-use OpenAI Computer Use guide: https://platform.openai.com/docs/guides/tools-computer-use OpenAI Computer Use safety guide: https://platform.openai.com/docs/guides/tools-computer-use#safety Anthropic Computer Use documentation: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool OWASP LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ OWASP LLM06 Excessive Agency: https://genai.owasp.org/llmrisk/llm06-excessive-agency/ OWASP LLM02 Sensitive Information Disclosure: https://genai.owasp.org/llmrisk/llm02-sensitive-information-disclosure/

AI 自动写代码已经不再只是补全几行函数。现在的代码 Agent 能读仓库、理解报错、修改多个文件、运行测试、解释失败、生成提交说明，甚至能在浏览器里复现问题。它的价值很直接：把开发者从重复定位、样板修改、测试修补和文档同步里解放出来。但它也带来一个新的治理问题：当一个非人类执行者开始持续改动代码库，团队到底怎么管？ “管”不是把 AI 关起来，也不是每一步都让人手工复制粘贴。真正有效的治理，是让 AI 的产出进入正常工程系统：代码审查、自动化测试、权限边界、变更记录、依赖安全、回滚机制、发布节奏和责任归属。AI 可以更快地产生改动，但不能绕过软件工程的基本事实：代码最终运行在用户环境里，错误最终由团队承担，安全缺口最终会变成真实风险。 很多团队的问题不是“AI 会不会写代码”，而是“AI 写的代码能不能被可靠接收”。如果 AI 直接在主分支提交，缺少测试，权限过大，审查流于形式，回滚路径不清楚，那么速度越快，事故越快。相反，如果把 AI 当作受约束的开发参与者，让它只能在任务边界内修改、必须跑测试、必须提交可审查 diff、必须通过权限和规则检查，它就能成为生产力，而不是新的不确定性来源。 一、先把 AI 代码 Agent 当成“会行动的开发者” 传统代码助手更像输入法，开发者接受哪一行、改哪一行都很清楚。代码 Agent 不同，它会自主探索仓库，做出一串操作。它可能先搜索报错，再修改后端，再补前端，再跑测试，再改配置。这个过程中，它拥有比补全工具更大的行动面。治理方式也必须升级：不能只看最终代码片段，还要看任务、过程和证据。 把 AI 代码 Agent 当成“会行动的开发者”，意味着它也要遵守分支策略、审查规则、测试要求、安全扫描和发布流程。它不能因为是 AI 就免审，也不能因为速度快就跳过状态检查。GitHub 的分支保护、必需状态检查、Pull Request 审查、Code Owners、规则集等机制，本来就是为了让代码进入主分支前经过可重复的控制点。AI 改动应该进入这些控制点，而不是绕过去。 同时，AI 又不是人类开发者。它没有真实责任感，不天然理解团队历史，不会自动知道哪些隐性约定不能碰，也可能在上下文不足时自信地改错。治理设计不能假设模型“应该知道”。凡是重要边界，都要放到工具权限、仓库规则、测试和审查清单里。AI 的强项是快速阅读、生成和试错；系统的职责是限制它的破坏面。 对团队来说，第一步是给 AI 代码 Agent 明确角色。它可以是代码修复助手、测试补全助手、迁移助手、重构助手、文档同步助手、依赖升级助手、审查助手。不同角色对应不同权限和验收标准。修 bug 可以改实现和测试；文档同步不应改业务逻辑；审查助手只应评论，不应直接提交；依赖升级助手必须触发安全和兼容性测试。角色越清晰，治理越容易。 不要把“AI 能做什么”直接等同于“AI 应该做什么”。一个 Agent 也许能删除文件、改数据库迁移、更新 CI、重写鉴权、推送主分支，但这些能力不应该默认开放。生产级治理的核心，是把可做能力切成可授权能力，再按任务开放最小集合。 二、任务边界：不要让 AI 在仓库里自由漫游 AI 自动写代码最常见的事故，是改动范围失控。用户让它修一个按钮，它顺手重构全局样式；用户让它补一个接口字段，它修改鉴权中间件；用户让它修测试，它把测试断言改弱；用户让它升级依赖，它改了构建脚本和运行时配置。很多时候不是模型恶意，而是任务边界没有写清，工具也没有限制。 每个 AI 编码任务都应有任务契约：目标、允许修改范围、禁止触碰范围、预期验证方式、完成物。目标回答“要解决什么问题”；允许范围回答“可以动哪些目录和文件”；禁止范围回答“哪些文件不能碰”；验证方式回答“如何证明完成”；完成物回答“需要提交 diff、测试结果、说明还是 PR”。任务越大，契约越重要。 文件权限应尽量技术化，而不只写在提示词里。比如文档任务只开放 docs/，前端样式任务只开放相关组件和样式文件，单元测试任务开放测试文件和对应实现，配置任务必须人工确认。很多 Agent 框架和本地工具都支持只读模式、写入确认、命令确认、路径白名单或沙盒。开发阶段也要用这些机制，因为习惯会延续到生产。 边界还包括“不修改用户已有改动”。团队环境里，AI 不是独占代码库。工作区可能有其他人的未提交改动，分支上可能有未推送提交，文件可能正在被编辑。AI 在动手前应查看 Git 状态，识别未跟踪文件、未暂存修改和当前分支。若要修改已有改动所在文件，必须先读清楚并避免覆盖。最差的体验不是 AI 写错，而是 AI 把人的工作覆盖掉。 任务边界也要限制“顺手优化”。AI 很擅长发现旁边的坏味道，于是可能在修一个 bug 时改命名、格式化全文件、调整结构、替换库。除非任务明确要求重构，否则应该坚持最小可行改动。最小改动不是保守，而是让审查、测试和回滚都更可靠。大重构可以做，但应独立成任务，独立评审。 对大型改动，边界应分阶段确认。比如“把旧状态管理迁移到新方案”不能让 Agent 一口气全仓库改完。更稳妥的流程是先让它生成影响分析，列出模块和风险；再选一个垂直切片试改；跑测试和截图验收；再扩大范围。AI 能加速迁移，但不能省略迁移治理。 三、代码审查：审 AI 代码，更要审 AI 的理由和证据 AI 代码审查不能只问“代码看起来能不能跑”。它还要问：这个改动是不是解决了原问题？有没有超出范围？有没有把测试改弱？有没有引入安全风险？有没有依赖未验证假设？有没有隐藏用户可见文案或内部字段？有没有把错误吞掉？有没有用硬编码绕过真正问题？ GitHub 的 Pull Request 审查、必需批准、Code Owners 和分支保护机制，适合承接 AI 改动。AI 可以开 PR，人类或审查 Agent 可以评论，CI 给出状态，最终由有权限的人合并。关键是不要让 AI 直接把改动推到受保护分支。主分支保护不是形式，它是防止高速错误进入主线的最后闸门之一。 审查 AI 代码时，第一眼看 diff 范围。文件数量是否符合任务？是否出现无关格式化？是否修改了锁文件、迁移文件、鉴权、权限、CI、环境变量、密钥读取、日志输出等高风险区域？如果范围不合理，先要求缩小，不要陷入逐行争论。范围失控的 PR，即使每一行看起来不错，也会增加回归和回滚成本。 第二眼看行为链。AI 的说明应包含问题原因、改动策略、验证命令和结果。审查者要检查这些证据是否真实：测试是否实际运行，失败是否解释清楚，截图是否对应目标页面，API 响应是否来自本地服务，性能数据是否可复现。AI 很容易写出漂亮总结，但治理看的是证据，不是语气。 第三眼看测试变化。AI 如果为了让 CI 通过而删除断言、放宽条件、跳过测试、扩大 mock、降低覆盖，就把问题转移到了未来。测试修改不是不能做，但必须解释旧测试为什么不再适用，新测试覆盖了什么真实行为。对 bug 修复，最好先有失败用例，再有修复。对 UI 改动，至少要有关键交互或截图验收。对安全改动，必须有拒绝路径测试。 第四眼看异常处理。AI 常用的坏修法是捕获所有异常、返回默认值、吞日志、重试无限次、把错误展示给用户、用空对象兜底。这些写法会让问题暂时消失，却让系统更难诊断。生产级代码应区分可恢复错误、用户输入错误、权限错误、外部系统错误和内部错误。AI 写的异常处理尤其需要审。 第五眼看安全和隐私。是否把密钥写进代码或日志？是否把用户输入拼进命令或 SQL？是否扩大 CORS？是否绕过权限检查？是否把内部字段返回给前端？是否在错误页展示堆栈？是否引入未维护依赖？GitHub CodeQL、secret scanning、Dependabot、OpenSSF Scorecard 等工具可以自动发现一部分问题，但审查者仍要理解业务风险。 代码审查也可以用 AI 辅助，但不能让同一个 Agent 自己改、自己审、自己合并。审查 Agent 可以检查范围、风险、测试缺口和风格一致性；人类审查者负责最终判断，尤其是业务语义、安全边界和用户体验。AI 审查应留下具体评论，而不是泛泛说“看起来没问题”。 四、测试：AI 改动必须被可执行事实约束 AI 写代码最需要测试，因为模型擅长生成“看起来合理”的实现。没有测试，审查者只能靠阅读和经验判断；有测试，团队至少能知道某些行为仍然成立。测试不是为了证明 AI 永远正确，而是为了把错误尽早暴露在可重复环境里。 测试要分层。小改动至少跑相关单元测试；跨模块改动要跑集成测试；前端交互要跑组件测试、端到端测试或浏览器截图；数据库改动要跑迁移和回滚测试；接口改动要跑契约测试；安全改动要跑拒绝路径。不要用一个笼统的“测试通过”代替具体命令和范围。AI 最终说明应写清运行了什么、结果如何、没能运行什么。 CI 是 AI 代码治理的基础设施。GitHub Actions、GitLab CI、Jenkins 或本地流水线都可以承担自动检查。受保护分支应要求关键状态检查通过后才能合并。必需状态检查的意义在 AI 场景更大，因为 AI 改动速度快，人工审查时间有限，自动门禁能拦住大量低级错误。 但 CI 不能只跑快乐路径。AI 常常会根据现有测试优化，而不是根据真实需求优化。如果测试覆盖不足，它可能写出碰巧通过的实现。团队应持续补业务关键路径测试，尤其是权限、边界条件、并发、错误恢复和数据兼容。AI 可以帮忙补测试，但测试目标应由业务风险驱动。 对于代码 Agent，测试工具返回要可读。不要只把几千行日志丢给模型。更好的工具会返回命令、退出码、失败测试名、关键错误片段和日志文件路径。模型据此修复失败，而不是在噪声中猜。测试失败应成为下一步输入，不是终止理由。 AI 修改测试时要格外谨慎。允许它新增测试、修正明显过期的测试夹具、补充边界用例；限制它删除失败测试、跳过测试、扩大 mock、把断言变成快照垃圾桶。若确实需要改旧测试，应要求解释行为变更依据。很多生产事故都来自“测试也跟着错改了”。 前端和产品型改动还需要真实用户路径验收。截图和浏览器操作比单纯构建更接近用户体验。比如表单按钮、错误页重试、中文输入法、移动端布局、权限提示，单元测试很难完全覆盖。AI 做完后应打开页面、完成关键流程、检查文字是否面向最终用户。生产级 UI 标准不能靠代码编译通过来保证。 五、权限：最小授权比“相信模型”可靠 AI 代码 Agent 的权限至少包括文件读写、命令执行、网络访问、包安装、Git 操作、密钥访问、浏览器操作、云资源操作和发布权限。每一项都可能造成风险。最小权限原则要求：当前任务不需要的能力就不要开放，需要的能力也尽量限制范围和确认点。 文件读写权限应区分只读、建议补丁、可写和需确认写。很多任务只需要读代码并给建议，不需要直接写。可写时应限制工作目录，避免访问用户主目录、密钥目录、生产配置和无关仓库。路径白名单比提示词可靠。若任务只涉及一个项目，就不要让 Agent 横跨多个项目搜索和修改。 命令执行权限是高风险点。测试命令、格式化命令、类型检查通常可控；安装脚本、远程下载、数据库迁移、删除命令、权限修改、部署命令需要确认；涉及 curl | sh、读取环境变量、上传文件、修改系统配置的命令应默认禁止或人工审查。OpenAI Codex、Claude Code 等工具都强调沙盒、审批和权限模式，原因就在这里。 网络权限也要管。AI 可能为了修 bug 查文档、下载包、访问外部服务。这有价值，但也可能泄露代码、日志或密钥。企业环境中应通过代理、域名白名单、只读文档源和依赖仓库控制网络访问。模型不应把私有代码片段发给未知站点，也不应从随机博客复制安全敏感代码。 密钥和凭证必须隔离。Agent 不应该读取长期生产密钥。需要调用服务时，应使用短期、最小权限、可审计的凭证。测试环境和生产环境要分开。日志、错误消息和最终回答都不应包含密钥、令牌、Cookie、个人信息。GitHub secret scanning 等机制可以补防线，但根本策略是让 Agent 看不到不该看的东西。 Git 权限也要分级。读取状态和生成 diff 风险低；创建分支和提交需要任务授权；推送远端、合并 PR、打标签、发布版本属于高风险。AI 可以准备提交，但最终是否推送和合并，应由规则和负责人控制。对于自动化维护任务，可以给专用机器人账号有限权限，并要求所有变更走 PR。 权限还要和身份绑定。团队需要知道某个改动由哪个用户发起、哪个 Agent 执行、用了什么模型、调用了哪些工具。不要让所有 AI 操作共用一个不可追踪的超级账号。审计身份越清楚，事故后越容易回放和改进。 六、回滚：没有撤退路线，就不要自动前进 AI 代码治理必须提前设计回滚。因为 AI 改动速度快，改动数量可能多，错误也可能隐藏在边界场景里。如果回滚路径不清楚，团队上线时会犹豫；如果回滚路径可靠，团队可以更大胆地让 AI 处理低风险任务。 最基本的回滚是 Git 回滚。每个 AI 任务应形成清晰提交或 PR，避免把多个无关任务混在一起。小而聚焦的提交可以用 git revert 或平台回滚功能撤销；大杂烩提交会让回滚变成二次开发。Git 官方文档中的 git revert 思路很适合生产：通过新提交反向应用旧提交，保留历史，而不是改写共享历史。 PR 级回滚也很重要。GitHub 支持对已合并 PR 创建回滚 PR。这个机制要求原 PR 范围清楚、冲突少、提交关系简单。AI 变更如果遵守最小改动和单一目标，回滚成功率会高很多。反之，一个 AI PR 同时改业务逻辑、样式、依赖、配置和测试，回滚时很容易冲突。 部署回滚比代码回滚更复杂。上线后发现问题，不一定马上 revert 代码就能恢复。数据库迁移、缓存结构、队列消息、外部 API、用户数据写入都可能不可逆。AI 涉及这些区域时，必须有发布计划：向前兼容迁移、灰度开关、特性开关、数据备份、回滚脚本、监控指标和人工确认。自动写代码不能绕开发布工程。 特性开关是 AI 改动的好搭档。对于新行为，可以先隐藏在开关后，小范围灰度，观察指标，再扩大。回滚时先关开关，比紧急改代码更快。Martin Fowler 关于 Feature Toggles 的实践长期强调，开关既能支持持续交付，也会带来管理成本。AI 场景同样如此：开关要有所有者、过期时间和清理计划，不能无限堆积。 依赖升级和生成代码也需要回滚策略。AI 升级一个库可能改变锁文件、打包结果、运行时行为。回滚时不仅要还原版本，还要考虑迁移代码是否依赖新 API。生成代码如果覆盖手写逻辑，应保留可审查来源和生成边界。回滚不是“删掉 AI 写的东西”这么简单，而是恢复系统行为。 回滚演练比回滚文档更可靠。团队可以定期选取一个低风险 AI PR，模拟回滚：能否找到变更、能否 revert、测试是否通过、部署是否恢复、数据是否需要处理。演练会暴露提交粒度、测试缺口和发布脚本问题。没有演练的回滚方案，往往只存在于想象中。 七、供应链安全：AI很容易引入看不见的依赖风险 AI 写代码时，经常会建议安装新包、复制示例代码、调整构建插件、添加 GitHub Action、改变 Docker 镜像。每一次都是供应链入口。OpenSSF 的 SLSA 框架、Scorecard、GitHub Dependabot、CodeQL 和 secret scanning 等工具，都是为了解决软件供应链和代码安全中反复出现的问题。AI 加速写代码后，这些工具更应该成为默认门禁。 新增依赖要问五个问题：是否真的需要；是否维护活跃；许可证是否可接受；是否有已知漏洞；是否能被现有依赖替代。AI 可能为了几行功能引入一个大包，也可能推荐过期库。Dependabot 可以提示已知漏洞，但不能判断业务必要性。审查者应要求 AI 解释为什么新增依赖，而不是默认接受。 CI 工作流变更要严格审。AI 可能为了让测试通过修改 GitHub Actions 权限、缓存、脚本或触发条件。GitHub Actions 安全加固文档长期提醒，GITHUB_TOKEN 权限、第三方 Action、pull_request 触发、脚本注入都需要谨慎。对 AI 生成的 CI 改动，尤其要检查是否扩大写权限、是否运行不可信代码、是否泄露 secret。 生成代码也有版权和来源问题。AI 可能复现训练中见过的片段，也可能从网络资料中改写。团队应避免让 Agent 从未知来源复制大段代码，尤其是许可证不明的实现。使用官方文档和项目文档作为参考更稳妥。对关键算法和安全代码，应要求来源、测试和人工审查。 容器和基础镜像同样要管。AI 可能把镜像改成 latest，可能用不受信任的镜像源，可能在 Dockerfile 里下载脚本。生产项目应固定版本、使用可信源、扫描镜像漏洞、最小化运行权限。AI 不应为了“构建能过”牺牲供应链可控性。 供应链治理的关键不是让 AI 不碰依赖，而是让每次依赖变化都可见、可评审、可扫描、可回滚。把依赖、构建和 CI 当成高风险文件，自动加审查人，是很实用的做法。 八、审查清单：AI 代码 PR 该看什么 第一项，任务一致性。PR 是否只解决描述中的问题？有没有顺手改无关功能？有没有把临时调试代码留下？有没有新增与任务无关的抽象？如果标题说修登录，diff 却动了支付模块，就要先停。 第二项，行为正确性。改动是否符合业务规则？是否处理了空值、边界、错误、权限和并发？是否保持向后兼容？是否改变了公开 API、数据结构或用户可见文案？这些问题需要结合业务上下文看，AI 自己的总结不能替代判断。 第三项，测试证据。是否新增或更新了合适测试？是否运行了相关测试命令？CI 是否通过？未运行的测试是否有合理原因？测试是否覆盖失败路径？有没有跳过或削弱测试？ 第四项，安全隐私。是否新增输入拼接、命令执行、反序列化、文件上传、权限绕过、敏感日志、跨域放宽、密钥读取？是否暴露内部字段和调试信息给最终用户？是否符合最小权限？ 第五项，依赖和供应链。是否新增包、Action、镜像、脚本下载或构建插件？版本是否固定？来源是否可信？许可证和漏洞是否检查？是否有不必要的重量级依赖？ 第六项，可维护性。代码是否符合项目风格？是否使用已有工具和模式？是否引入重复逻辑？抽象是否过度？注释是否解释复杂原因而不是重复代码？AI 很容易写“看起来完整”的通用层，但项目未必需要。 第七项，可回滚性。PR 是否小而聚焦？是否有数据库迁移、数据写入或不可逆操作？是否需要特性开关？是否说明回滚方式？合并后如果出问题，能否快速撤销？ 第八项，用户体验。界面文案是否面向最终用户？是否出现内部字段、调试术语、实现细节？错误提示是否能指导下一步？中文输入、移动端布局、加载状态、空状态是否被考虑？AI 代码治理不只管后端安全，也管用户看到什么。 九、AI Agent 自己也要被评测 团队不应只评估模型在 benchmark 上的分数，还要评估 Agent 在本仓库的工作质量。代码 Agent 的真实指标包括：任务完成率、一次通过率、平均改动范围、测试通过率、回归率、人工修改比例、审查评论数量、越权尝试次数、失败恢复率、回滚次数。没有这些指标，团队只能凭感觉说“AI 好像有用”。 评测任务应来自真实历史问题。可以选取已修复 bug、常见小需求、测试补全、文档同步、依赖升级、重构切片，让 Agent 在隔离分支上尝试。评估时不要只看最终是否能编译，还要看它是否走了合理路径、是否修改过多、是否写了测试、是否说明不确定性。SWE-bench 等公开评测说明了真实仓库任务的重要性，但每个团队还需要自己的本地任务集。 评测要区分任务类型。AI 可能非常适合补测试和修小 bug，但不适合重写支付逻辑；可能适合迁移样板代码，但不适合设计新架构；可能适合解释报错，但不适合直接操作生产。把所有任务混成一个“AI 成功率”，会掩盖真实边界。 失败样本比成功样本更有价值。每次 AI 改错、测试没跑、权限越界、生成无关代码、误删文件，都应进入案例库。团队可以从案例中改进提示、工具权限、任务模板、测试门禁和审查清单。治理不是一次性制度，而是持续学习。 也要评估成本。AI 可能减少编码时间，但增加审查时间；可能节省测试编写，却增加 CI 消耗；可能让低级需求更快，却让大 PR 更难理解。有效指标应看端到端周期和质量，而不是只看模型生成速度。 十、组织流程：让 AI 进入现有工程秩序 AI 代码治理最终是组织问题。谁可以发起 AI 改动？哪些仓库允许？哪些目录禁止？AI 生成的 PR 谁负责审？失败后谁处理？安全问题谁确认？发布谁批准？如果这些问题没有答案，AI 就会在团队里形成灰色流程。 建议为 AI 改动建立轻量标签和模板。PR 标题或标签标明由 AI 辅助，描述中包含任务目标、改动范围、验证结果、风险点和回滚方式。不是为了贴标签歧视 AI，而是让审查者知道需要关注过程证据。GitHub Copilot 等工具的负责使用文档也强调，开发者需要审查、测试和理解 AI 建议，责任不能转移给模型。 高风险仓库应设置更严格规则。涉及认证、支付、隐私、基础设施、发布流水线、数据迁移的项目，不应允许 AI 直接写入主线。可以允许 AI 在分支上生成补丁，但必须由负责人审查和手动合并。低风险内部工具、测试补全、文档站点可以给更宽松权限，但仍要保留回滚和审计。 团队还应区分个人本地 Agent 和集中式自动 Agent。个人本地 Agent 更像开发者工具，受个人权限影响；集中式 Agent 可能接入工单、CI、代码托管和部署系统，影响面更大。集中式 Agent 必须有服务账号、权限边界、日志、速率限制和人工审批。不要让一个自动化机器人拥有比任何人都大的权限。 培训也很重要。开发者要知道如何给 AI 明确任务、如何阅读 AI diff、如何要求测试、如何拒绝不合理改动、如何处理失败。审查者要知道 AI 常见坏味道：过度抽象、吞异常、弱化测试、硬编码、复制旧模式、忽略权限、编造 API。治理制度如果不能落到日常操作，就会变成文档。 十一、落地路径：从低风险自动化开始 团队引入 AI 代码 Agent，不必一开始就让它修核心业务。更稳妥的路径是从低风险、高重复、容易验证的任务开始。比如补充测试、修复 lint、更新文档、生成迁移说明、整理错误日志、定位失败测试、升级小版本依赖、给 PR 做风险摘要。这些任务价值明确，失败成本较低，容易建立信任。 第二阶段可以进入小型 bug 修复和垂直切片。要求 Agent 在独立分支工作，输出 diff 和测试结果，人工审查后合并。此时重点观察改动范围、失败恢复和测试质量。不要急着追求完全自动合并，先把“AI 生成可审查 PR”的链路跑稳。 第三阶段再考虑半自动维护任务。比如定期依赖升级、批量代码迁移、重复模式修复。每类任务都应有专用模板、权限、测试和回滚策略。自动化程度可以逐步提高：先生成建议，再生成 PR，再在低风险条件下自动合并。每一步都要有指标和回退。 核心业务和高风险操作要长期保留人类审批。AI 可以做分析、生成补丁、写测试、解释影响，但最终合并、发布和数据变更应由负责人把关。生产级不是拒绝自动化，而是知道哪些地方不能无人值守。 落地过程中，工具体验会直接影响治理质量。如果 Agent 很难运行测试，它就会少跑；如果 diff 不清楚，审查就会变慢；如果权限确认太频繁，用户会机械批准；如果错误信息太差，模型会乱改。治理不是额外负担，而是要把正确路径做成最顺手的路径。 十二、一个可执行的团队制度样例 对普通功能修复，团队可以规定：AI 只能在任务分支修改；开始前检查工作区状态；改动范围限于相关模块；必须运行相关测试或说明无法运行原因；PR 描述必须包含问题、方案、验证和回滚；至少一名人类审查通过；CI 必须通过；禁止 AI 直接合并主分支。 对安全敏感改动，规则更严格：涉及鉴权、权限、加密、密钥、支付、个人信息、CI 权限、生产配置、数据库迁移的改动自动加安全负责人审查；必须有拒绝路径测试；不得扩大日志敏感信息；不得新增未审查依赖；上线前需要回滚方案。 对文档和测试补全，规则可以放宽：AI 可自动生成 PR；CI 通过且无代码逻辑变更时可快速审查；但仍需检查是否泄露内部字段、是否误导用户、是否与实际行为一致。低风险不等于无风险，尤其是面向用户的文案。 对自动依赖升级，规则应包含：只允许受信任源；版本变更可见；安全公告和 changelog 进入 PR；测试矩阵通过；重大版本不得自动合并；回滚命令清楚。Dependabot 可以发起升级，AI 可以辅助总结影响，但负责人仍要判断兼容性。 对本地开发 Agent，规则应提醒开发者：不要给它生产密钥；不要让它修改无关仓库；高风险命令先读再批；保留 Git 状态；提交前自己复查 diff。个人效率工具也会影响团队代码库，不能完全个人化。 十三、不同代码任务的治理强度 AI 写代码不是一种任务，而是一组风险差异很大的任务。把所有任务套同一套审批，会让低风险工作变慢，也会让高风险工作被低估。更好的办法是按任务类型分级，让治理强度和真实后果匹配。 最低风险的是只读分析和解释。比如解释报错、梳理模块结构、总结 PR 风险、列出可能影响文件。这类任务可以开放较宽读取权限，但仍要避免读取密钥、私有凭证和无关目录。只读不代表无风险，因为代码和日志本身可能包含敏感信息。对外部模型尤其要注意数据边界，避免把未授权代码发给外部服务。 较低风险的是文档、注释、示例和测试补全。它们通常不直接改变运行时行为，但会影响开发者理解和用户判断。文档错误可能误导运维，测试错误可能掩盖缺陷，示例错误可能被复制到生产代码。因此这类任务可以给 AI 较高自主度，但仍要审查事实、命令、路径、参数和用户可见表述。面向用户的文案尤其不能出现内部字段和调试话术。 中等风险的是局部 bug 修复和小功能。它们会改变运行时行为，必须有测试和审查。AI 可以自主定位和生成补丁，但应限制范围，避免把问题扩大成重构。对这类任务，最重要的不是让 AI 一次写对，而是让它能用测试失败继续修正，并在完成时给出真实验证证据。 较高风险的是跨模块重构、依赖升级、构建系统和 CI 修改。这些改动常常影响面广，单点测试不够。AI 做这类任务时，应先输出影响分析和计划，再分批提交。依赖升级要看 changelog、漏洞、许可证和兼容性；CI 修改要看权限、触发条件和 secret 暴露；重构要看公共接口和回滚难度。 最高风险的是鉴权、支付、隐私、数据迁移、生产配置、基础设施和发布流程。AI 可以辅助分析、写测试、准备补丁和生成回滚步骤，但不应无人值守执行。正式修改需要负责人审查，发布需要灰度和监控，数据动作需要备份和恢复路径。这里的原则很清楚：AI 可以加快准备工作，但不能替代责任人批准。 这种分级还有一个好处：团队能逐步扩大 AI 使用范围。先在低风险任务里积累样本和信任，再把成功模式迁移到中风险任务，最后让 AI 辅助高风险任务的分析和测试。不要从最难、最危险、最难验收的任务开始证明 AI 能力，那会把技术试点变成风险实验。 十四、日志和审计：把过程留下来 AI 自动写代码的审计，不是为了制造负担，而是为了让团队知道发生了什么。一次完整记录应能回答：谁发起任务，目标是什么，Agent 读了哪些关键文件，改了哪些文件，运行了哪些命令，测试结果是什么，哪些权限被批准，哪些步骤失败，最终由谁合并。没有这些信息，出了问题只能看最终 diff，很难还原原因。 日志要有层次。普通开发者需要看到简洁过程和验证结果；审查者需要看到 diff、测试和风险点；安全人员需要看到权限、依赖、密钥扫描和高风险命令；平台团队需要看到模型版本、工具版本、执行时长和失败类型。不要把所有原始输出直接堆进 PR，也不要完全隐藏过程。好的审计是可读、可搜索、可追溯。 命令日志尤其重要。AI 说“测试通过”不够，应该记录具体命令和退出状态。AI 说“无法运行测试”也不够，应该记录失败原因，是依赖缺失、环境不支持、权限不足，还是测试本身失败。这样审查者才能判断风险。对无法运行的检查，PR 不应伪装成完整验证，而应明确剩余风险。 权限批准也应可追踪。谁批准了写文件，谁批准了安装依赖，谁批准了推送分支，谁批准了访问外部网络，这些记录能帮助团队发现权限设计是否过宽。如果大家每天都机械批准同一个高风险命令，说明工具体验或权限模型有问题，应调整成更明确的任务级授权。 审计记录还可以反哺评测。哪些文件最常被 AI 误改，哪些测试最常失败，哪些命令最常需要人工批准，哪些任务最常被回滚，都能指导治理优化。真正成熟的团队，会把 AI 编码过程当作可观测系统，而不是一次次孤立对话。 十五、常见争议 争议一：AI 生成的代码是不是必须全部人工重写？不需要。关键不是来源，而是质量和证据。人写的代码也可能有 bug，AI 写的代码也可能正确。团队应审查行为、测试和风险，而不是用来源替代判断。 争议二：AI PR 要不要标明？建议标明 AI 辅助参与，至少在团队内部可见。这样有助于统计质量、优化流程和提醒审查者看证据。标明不代表降低标准，也不代表把责任推给 AI。 争议三：能不能让 AI 自动合并？低风险、规则明确、测试充分的维护任务可以逐步尝试，例如格式化、文档链接修复、非生产依赖补丁。但核心业务、权限、安全、数据和发布相关改动不应无人合并。自动合并应是治理成熟后的结果，不是起点。 争议四：AI 审查能不能替代人审？不能完全替代。AI 审查擅长发现模式问题、风险提示、重复逻辑和测试缺口，但业务语义、产品取舍、安全责任和架构方向仍需要人类负责。更合理的是 AI 先做机械审查，人类聚焦关键判断。 争议五：开发阶段是否需要这么严格？需要按风险分级，而不是完全放松。开发阶段确实不必套线上审批流程，但越早建立边界，越不容易形成坏习惯。尤其是权限、密钥、无关改动、测试弱化和回滚粒度，这些问题在开发期也会造成损失。 争议六：管太多会不会降低 AI 价值？会，如果治理只是一堆手工阻碍。不会，如果治理是自动门禁、清晰权限、好用测试和快速回滚。好的治理不是拖慢 AI，而是让团队敢用 AI。 十六、最终检查清单 任务开始前：是否明确目标、范围、禁止区域、验证方式；是否检查 Git 状态；是否确认当前分支；是否知道哪些命令需要审批；是否避免读取密钥和无关目录。 AI 修改中：是否坚持最小改动；是否优先复用项目现有模式；是否避免无关格式化；是否记录关键假设；是否在失败后根据证据修复；是否不为了过测试而削弱测试。 提交前：是否查看完整 diff；是否运行相关测试；是否检查新增依赖；是否检查敏感信息；是否确认用户可见文案；是否写清验证结果；是否说明未完成和风险。 PR 审查：是否有合适审查人；高风险文件是否加负责人；CI 是否通过；CodeQL、secret scanning、Dependabot 或同类检查是否启用；测试改动是否合理；回滚方式是否清楚。 合并发布：是否符合分支保护；是否需要特性开关；是否需要灰度；是否有监控指标；是否有回滚步骤；是否保留审计记录。 事后复盘：是否记录 AI 成功和失败样本；是否更新任务模板；是否调整权限；是否补测试；是否清理临时开关；是否把经验反馈到团队规范。 十七、结语：让 AI 更快，也让工程更硬 AI 自动写代码的正确方向，不是把工程纪律交给模型自由发挥，也不是把 AI 限制成只能补全几行。更可持续的路径，是让 AI 进入成熟软件工程体系：小范围任务、清晰 diff、自动测试、权限分级、人工审查、供应链扫描、可回滚发布、可追踪审计。这样，AI 的速度才会变成团队速度，而不是风险速度。 代码 Agent 真正有价值时，它不是替团队绕过流程，而是把流程跑得更快：更快定位问题，更快生成补丁，更快补测试，更快解释风险，更快准备回滚。治理不是 AI 的刹车，而是让它能在真实代码库长期工作的轨道。 延伸阅读和来源链接 GitHub Docs：About pull request reviews，https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews GitHub Docs：About protected branches and required status checks，https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches GitHub Docs：Code scanning and CodeQL，https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning GitHub Docs：Secret scanning，https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning GitHub Docs：Dependabot alerts，https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts NIST：Secure Software Development Framework SP 800-218，https://csrc.nist.gov/publications/detail/sp/800-218/final NIST：AI Risk Management Framework 1.0，https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 OpenSSF：SLSA framework，https://slsa.dev/spec/ OpenSSF：Scorecard，https://scorecard.dev/ GitHub Docs：Security hardening for GitHub Actions，https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions Anthropic：Claude Code security，https://docs.anthropic.com/en/docs/claude-code/security OpenAI：Codex permissions，https://developers.openai.com/codex/permissions Git：git revert documentation，https://git-scm.com/docs/git-revert GitHub Docs：Reverting a pull request，https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reverting-changes-in-pull-requests/reverting-a-pull-request Martin Fowler：Feature Toggles，https://martinfowler.com/articles/feature-toggles.html GitHub Docs：Responsible use of GitHub Copilot，https://docs.github.com/en/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-code-completion 写作日期：2026-05-22

多智能体协作听起来很自然：一个智能体负责规划，一个负责搜索，一个负责写作，一个负责评审，一个负责执行，大家像团队一样分工，最后得到更好的结果。很多演示也确实漂亮：几个角色轮流发言，互相质疑，自动拆任务，自动调用工具，最后产出一份报告、一段代码或一个方案。问题是，真实生产环境不是角色扮演。多一个智能体，就多一份上下文成本、多一条错误传播路径、多一个协调点、多一组权限和状态问题。协作如果没有明确收益，很容易从“群体智能”变成“群体消耗”。 多智能体协作真正有用的时候，通常不是因为模型需要更多人格，而是因为任务天然存在分工、冲突检查、并行探索、专业边界或风险复核。一个智能体能稳定完成的任务，不必拆成多个智能体。固定流程能解决的任务，不必伪装成开放协作。只有当单一智能体在视角、工具、权限、上下文或验收上明显不足时，多智能体才值得引入。 这篇文章讨论一个务实问题：多智能体协作什么时候有用，什么时候没有用。我们把协作拆成四个核心场景：讨论、评审、执行和防内耗。讨论用于探索方案，评审用于发现错误，执行用于把复杂任务拆到不同能力边界，防内耗用于控制成本、循环和责任不清。目标不是追求“看起来很多AI在工作”，而是让AI系统在真实任务里更可靠、更可控、更能交付。 一、多智能体不是更高级的默认形态 很多团队一开始做Agent，就想做多智能体。原因很容易理解：现实中的人类团队就是分工协作，软件开发有产品、架构、开发、测试、运维，内容生产有策划、资料、作者、编辑、审校，企业流程有申请、审批、执行、复核。把这些角色映射成多个智能体，看起来符合组织经验，也更容易做出复杂演示。 但大模型智能体不是人。人类团队里的角色拥有长期记忆、组织责任、专业训练、真实权限和社会约束；智能体角色通常只是Prompt、工具集合、上下文窗口和一段调度逻辑。给模型起名为“架构师”“审计员”“执行官”，并不会自动产生可靠专业分工。如果每个智能体背后都是同一个模型、同一批资料、同样的错误倾向，只是换了口吻，多智能体可能只是把同一种偏差重复多次。 Anthropic在讨论有效Agent时区分了workflow和agent：路径清楚、步骤固定的任务，工作流通常更可靠；路径开放、需要动态决策的任务，才更适合Agent。这个判断也适用于多智能体。很多任务看起来复杂，其实只是固定流水线：抽取字段、检索资料、生成摘要、格式校验、发送通知。这样的任务更适合单Agent加工具，或者确定性流程加模型节点，而不是让多个智能体自由聊天。 多智能体的成本也是真实的。每个智能体都需要上下文、指令、工具说明和状态同步；每轮交互都会增加token、延迟和失败概率；不同智能体之间的结论可能冲突，需要仲裁；工具权限如果分配不清，可能出现越权或重复操作；评审智能体如果没有独立证据，只会把执行智能体的话换一种方式赞同。协作不是免费增强，而是系统复杂度投资。 所以，多智能体设计的第一原则是：先证明单智能体或确定性流程不够，再引入协作。不是为了架构好看，也不是为了让日志热闹。判断标准很具体：是否需要多个视角减少盲点？是否需要独立评审降低风险？是否需要并行搜索缩短时间？是否需要不同工具权限隔离？是否需要专业子任务分别优化？如果答案都是否定的，多智能体大概率会变成内耗。 二、什么时候讨论有用：开放问题、方案分歧和未知空间 讨论型多智能体适合开放问题。比如新产品方案、架构选型、竞品研究、教学设计、复杂故障排查、法律风险初筛、市场进入策略。这类任务没有唯一标准答案，早期需要探索多种可能。一个智能体容易沿着第一条看起来合理的路线继续展开，多智能体讨论可以故意制造不同视角，让系统不那么早收敛。 讨论有用的前提是角色差异真实。不是“甲专家”“乙专家”轮流说泛泛观点，而是角色代表不同目标函数。产品视角关心用户价值和采用门槛，工程视角关心可实现性和维护成本，安全视角关心权限、数据和滥用风险，运营视角关心流程落地和反馈机制。不同角色必须有不同评判标准，否则讨论只会变成重复表达。 讨论还要有明确问题。比如“我们要不要上多智能体？”太空；“客服知识库问答是否需要增加独立事实核查Agent？”就具体得多。后者可以讨论证据来源、错误类型、延迟预算、核查成本、人工兜底和上线指标。问题越清楚，讨论越容易产出决策。多智能体不是头脑风暴聊天室，而是结构化争议生成器。 讨论型协作最适合在方案阶段使用，不适合无限延伸到执行阶段。早期让多个智能体提出选项、识别风险、列出假设很有价值；一旦路线确定，就应该收敛到负责人和执行计划。很多多智能体系统烂尾，是因为讨论没有结束条件。每个智能体都还能补充一点，每个风险都还能展开一点，最后没有人负责把结论变成下一步。 讨论要产出可比较选项，而不是产出更长文字。一个好的讨论结果应该包含：候选方案、适用条件、收益、代价、风险、需要验证的假设、推荐结论和反对意见。没有这些结构，讨论只是更复杂的长回答。多智能体讨论的价值不是“多说”，而是把关键不确定性摊开，让决策者看见取舍。 多智能体讨论也要避免伪多样性。如果多个智能体使用同一模型、同一温度、同一资料和相似Prompt，它们很可能在同一类错误上达成共识。要提升讨论质量，可以给不同角色不同资料优先级、不同审查清单、不同工具权限和不同输出任务。比如一个只看用户反馈，一个只看技术限制，一个只看合规条款，一个只看成本模型。差异越真实，讨论越有意义。 三、什么时候评审有用：高风险输出和可验证错误 评审型多智能体是最值得优先采用的模式之一。原因很简单：生成和评审是两种不同任务。生成者容易维护自己的叙事，评审者可以专注找错、找漏、找不满足约束的地方。代码评审、合同审阅、医学或法律信息、财务分析、对外发布内容、工具执行计划，都适合引入独立评审智能体。 评审有用的前提是有标准。没有标准的评审，只会变成“我觉得还可以”。评审智能体需要明确检查维度：事实是否有依据，引用是否能打开，计算是否可复算，格式是否满足Schema，是否遗漏用户问题，是否有越权承诺，是否泄露内部信息，是否触发高风险动作，是否需要人工确认。标准越清楚，评审越像质量门，而不是第二个作者。 评审还必须独立。独立不是完全不知道上下文，而是不能只依赖生成者的自我陈述。评审智能体应该能访问原始输入、资料来源、工具结果、代码diff、测试日志或业务记录。否则它只能评审语言是否顺滑，不能评审事实是否成立。一个执行智能体说“测试已通过”，评审智能体应该看测试输出，而不是相信这句话。 评审型协作特别适合“可验证错误”。代码是否通过测试、引用是否存在、金额是否相加正确、表格字段是否缺失、审批是否需要确认，这些都可以被查证。越能查证，评审越有价值。反过来，如果任务只是主观创意，比如广告标题风格，多个评审智能体可能会给出一堆互相冲突的偏好，增加噪音。 评审结果要能阻断流程。很多系统把评审智能体当装饰：它说有风险，执行还是继续；它说引用不足，最终答案还是输出。真正有用的评审应该连接到流程控制：通过、要求修订、请求人工确认、禁止执行。尤其是带副作用的工具操作，评审不通过就不能提交。 评审也有成本边界。低风险、低价值、可逆的任务，不一定需要多智能体评审。比如内部草稿润色、个人笔记摘要、简单格式转换，用单Agent自检或程序校验就够。评审智能体应优先用于高风险、高曝光、高成本错误场景。多智能体协作要把算力花在风险最高的地方。 四、什么时候执行有用：任务能拆成真实子责任 执行型多智能体适合复杂任务，但前提是任务能拆成真实子责任。真实子责任不是“你负责想，你负责写，你负责鼓励”，而是输入、工具、权限、输出和验收都不同。比如研究任务可以拆成资料搜集Agent、证据整理Agent、写作Agent和事实核查Agent；软件任务可以拆成定位Agent、修改Agent、测试Agent和评审Agent；业务流程可以拆成资料收集Agent、表单准备Agent、审批确认Agent和执行Agent。 子责任要有清晰交付物。资料搜集Agent交付来源列表和摘要，不交付最终结论；写作Agent交付正文，不擅自新增未经核验事实；测试Agent交付命令、结果和失败原因，不修改业务代码；审批Agent交付是否满足提交条件，不替用户点击不可逆操作。每个智能体都应该有自己的输入输出契约，否则协作会变成互相甩上下文。 执行型协作适合并行化。比如调研十个资料源，可以让多个检索Agent并行查不同来源；代码迁移可以让不同Agent检查不同模块；大文档审查可以让不同Agent负责事实、结构、合规和语言。并行的收益是时间和覆盖面。但并行之后必须有汇总和去重，否则最终结果会重复、冲突和层级混乱。 执行型协作也适合权限隔离。不是所有智能体都应该拥有所有工具。规划Agent可以只读，执行Agent可以写入，评审Agent可以读日志和diff但不能提交，发布Agent必须等待用户确认。权限隔离能减少模型误操作的伤害，也能让审计更清楚。把所有工具给所有智能体，再靠Prompt要求它们克制，不是生产级设计。 执行协作的难点是状态同步。一个Agent修改文件后，另一个Agent必须知道当前版本；一个Agent检索到新证据后，写作Agent必须知道证据可信度和限制；一个Agent执行失败后，规划Agent必须更新计划。LangGraph这类框架强调状态图、持久化和中断恢复，正是因为长任务不能只靠对话历史维持状态。多智能体越多，状态越要结构化。 执行型协作还需要仲裁机制。当两个Agent给出不同结论，谁说了算？可以由主管Agent仲裁，可以由评分器仲裁，可以由程序规则仲裁，也可以交给用户。关键是不能让冲突自然漂浮在最终回答里。用户需要的是结论和依据，不是看一群智能体各说各话。 五、什么时候多智能体没用：简单任务、假角色和无验收 多智能体在简单任务中常常没用。比如“把这段话改得更自然”“提取下面文本里的日期”“把JSON格式化”“解释一个概念”。这类任务输入明确、输出短、风险低，一个模型就能完成。拆成规划、执行、评审三层，只会增加延迟和成本。系统设计应该尊重任务复杂度，简单任务就走简单路径。 假角色也没用。所谓假角色，是多个智能体没有独立资料、没有不同工具、没有不同标准，只是被Prompt要求“扮演不同专家”。它们产生的分歧往往是随机措辞，产生的一致也不是可靠共识。多智能体要有真实差异：不同任务、不同信息、不同约束、不同权限、不同验收点。没有真实差异，角色越多越像戏剧，不像工程。 无验收的多智能体没用。几个智能体讨论很久，最后没有程序检查、没有证据引用、没有测试结果、没有用户确认，这并不会比单Agent更可靠。协作必须落到可验证结果：文件是否生成，测试是否通过，引用是否有效，风险是否关闭，用户动作是否完成。没有验收，多智能体只是把“不确定”包装得更热闹。 无状态的多智能体也很危险。每个智能体都只看一段对话摘要，容易丢失关键条件；一个Agent以为已经确认，另一个Agent不知道；一个Agent用旧资料，另一个Agent用新资料；最终汇总者又把冲突混在一起。多智能体系统必须把任务状态、资料版本、工具结果和决策记录保存下来。否则协作规模越大，漂移越严重。 另一个常见无效场景是“让模型互相说服”。多轮辩论有研究价值，也可能在某些推理任务中提高结果，但在生产里不能盲目使用。模型会被措辞、顺序和自信程度影响，未必因为事实而改变。辩论如果没有外部证据、没有评分标准、没有结束条件，就会增加成本并制造虚假的严谨感。 还有一种无效场景是“主管Agent万能调度”。很多架构图中间有一个Supervisor，周围挂满专业Agent。这个结构可以用，但主管不能只靠自然语言判断一切。它需要路由规则、任务状态、工具元数据、失败处理和人工介入条件。否则主管Agent自己也会迷路：该交给谁、何时停止、如何处理冲突、如何判断完成，都变成新的不确定性。 六、讨论模式：从发散到收敛 讨论模式适合解决“我们有哪些选择”而不是“请直接执行”。一个好的讨论流程通常分四步。第一步，明确问题和决策标准。第二步，不同角色分别给出方案和风险。第三步，互相质询关键假设。第四步，由汇总者形成推荐结论、保留意见和验证计划。没有第四步，讨论就不会收敛。 讨论角色要少而精。两个到四个通常足够。角色过多会导致每轮信息稀释，汇总压力增大。比如一个AI知识库产品方案，可以设产品Agent、工程Agent、数据Agent和风险Agent。产品Agent回答用户价值，工程Agent回答实现路径，数据Agent回答资料质量和评测，风险Agent回答误导和权限。每个角色都围绕自己的标准发言。 讨论不应该重复完整上下文。每个Agent拿到自己需要的摘要和证据即可，最终由汇总者拿完整状态。否则所有Agent都读同样材料、说同样内容，成本会飙升。上下文分配本身就是系统设计的一部分。多智能体协作不是让每个Agent都知道全部，而是让每个Agent知道自己负责判断的部分。 讨论要产出决策材料。比如用“方案A、方案B、方案C”的方式列出收益、成本、风险、适用条件和验证方式。不要把每个Agent的原话都贴出来。最终用户不需要看内部争论过程，需要看经过整理的结果。生产级UI和内容交付也应避免出现“某某Agent认为”这种开发者视角文案，除非产品本身就是面向调试。 讨论还要设置时间或轮次限制。比如每个角色一轮提案、一轮质疑、一轮回应，然后必须收敛。开放讨论如果没有上限，很容易变成循环。智能体总能找到新角度，但业务需要在有限信息下决策。多智能体系统必须承认“足够好”的完成条件。 讨论模式最重要的指标，不是生成多少观点，而是后续决策是否更稳。可以用这些问题评估：是否发现了单Agent漏掉的关键风险？是否提出了不同可行方案？是否减少了错误假设？是否让人工决策更快？如果讨论只增加篇幅，没有增加决策质量，就应该缩减。 七、评审模式：把独立检查做成质量门 评审模式可以设计成生成者和评审者分离。生成者负责完成任务，评审者负责按清单检查。比如写作任务中，作者Agent负责正文，事实核查Agent检查来源和断言，编辑Agent检查结构和重复，发布Agent检查面向用户的表达。代码任务中，修改Agent负责补丁，测试Agent运行命令，审查Agent检查风险和无关改动。 评审清单要和任务风险匹配。技术长文要查事实、来源、重复段落、标题层级和读者可读性；客服回复要查政策依据、承诺边界、情绪安抚和下一步；代码变更要查复现、测试、影响范围、安全和兼容；数据报告要查口径、公式、异常值和图表解释。评审智能体不应该泛泛说“更清晰一点”，而应该指出具体失败点。 评审输出要短而可执行。最好是通过、阻断、建议改进三类。阻断项必须有证据，建议项不能混进阻断项。否则执行者不知道哪些必须改，哪些只是偏好。评审型多智能体最怕“意见很多但没有优先级”。优先级不清会拖慢交付。 评审可以结合程序工具。代码评审要跑测试，文档评审可以统计字数和重复，引用评审可以检查URL，结构评审可以解析Markdown标题，数据评审可以重新计算。模型适合判断语义和风险，程序适合硬检查。把两者结合，比让多个模型互相点评更可靠。 评审要保留失败记录。每次评审发现的问题，都应该归类：事实错误、证据缺失、结构混乱、约束违反、格式错误、权限风险、工具失败。长期看，这些记录能反向改进生成Prompt、工具设计和任务边界。多智能体协作不只是当次提高质量，也应该积累可复用的质量知识。 评审也要防止过度保守。评审Agent如果被要求“找尽可能多问题”，可能会把正常取舍也当错误。对于开放内容，评审标准要区分事实错误、重要遗漏、表达建议和个人偏好。只有前两者应该阻断，后两者可以作为建议。生产流程不能让评审无限扩大权力。 八、执行模式：让每个智能体拥有清楚工作面 执行模式的关键是任务契约。每个智能体接收什么输入，允许什么动作，必须产出什么，失败时怎么报告，都要清楚。比如检索Agent的契约可以是：根据查询找到权威来源，输出标题、链接、发布时间、核心结论和可信度说明；不得写最终观点。写作Agent的契约可以是：只使用资料表中的信息写正文，缺证据处留空或标注无法判断；不得新增来源。核查Agent的契约可以是：逐条检查正文断言是否能回溯到资料。 执行模式要避免“上下文倾倒”。把所有资料都发给所有Agent，会浪费成本，也会增加干扰。检索Agent需要搜索目标和来源标准；写作Agent需要经过筛选的资料；核查Agent需要正文和资料映射；发布Agent需要最终版本和发布规则。不同工作面需要不同上下文。上下文越精准，模型越容易稳定执行。 执行模式里的工具要按角色分配。检索Agent有浏览器和搜索工具，写作Agent可能没有外网工具，测试Agent有命令执行工具，发布Agent有提交或发送工具但需要确认。工具分配不是为了麻烦，而是为了减少错误半径。如果写作Agent能随意搜索，它可能引入未经筛选的新信息；如果评审Agent能修改结果，它可能悄悄改变作者意图。 执行模式还需要汇总器。多个子任务输出后，必须有人去重、合并、排序、解决冲突。汇总器不是简单拼接器。它要知道最终用户目标，保留可靠结论，丢弃重复内容，标记冲突和不确定性。没有汇总器，多智能体输出常见问题是重复段落、风格不一、结论冲突和信息层级混乱。 执行模式的完成条件要外部化。不要让执行Agent自己说完成就完成。检索完成要看来源数量和质量，写作完成要看字数、结构和引用，代码完成要看测试，业务操作完成要看系统返回状态。完成条件可以由程序、评审Agent或人工共同判断。多智能体执行最怕每个Agent都说“我这边好了”，但整体任务没有完成。 执行模式还要支持恢复。长任务中某个Agent失败，不应该让整个任务从头开始。状态图、检查点、可重试步骤和失败报告很重要。比如资料检索失败可以换来源，写作失败可以保留大纲重写，测试失败可以回到修改Agent，发布失败可以保留草稿等待确认。没有恢复机制，多智能体越复杂，失败体验越差。 九、防内耗：控制循环、冲突和成本 多智能体内耗最常见的形态是循环。规划Agent交给执行Agent，执行Agent提出问题，规划Agent重新规划，评审Agent又要求补充，执行Agent再回去查，最后任务一直不结束。循环不一定是坏事，修复失败需要迭代；但循环必须有上限、目标和退出条件。比如最多两次修订，连续失败则报告阻塞；同一工具错误不得重复三次；信息不足必须追问用户。 第二种内耗是冲突不解决。一个Agent认为可以上线，另一个Agent认为风险高，汇总者把两边都写进最终回答，让用户自己判断。这不是协作，是转嫁责任。系统必须有冲突处理规则：硬约束优先于偏好，证据充分优先于主观判断，高风险评审优先于执行者自评，人工确认优先于自动动作。规则越早定义，协作越少扯皮。 第三种内耗是重复劳动。多个Agent都去查同一资料、都写同一部分、都检查同一格式。重复有时可以用于独立验证，但必须有目的。没有目的的重复只是浪费。可以通过任务分片、共享资料库、结果缓存和清晰职责减少重复。需要独立验证时，也要让两个Agent使用不同方法或不同来源，而不是重复同一路径。 第四种内耗是成本失控。多智能体系统的token和延迟增长很快。每个角色都读完整上下文、每轮都输出长篇解释、每个步骤都评审，会让产品不可用。成本控制要从设计阶段开始：简单任务走快速路径，复杂任务才走协作路径；低风险任务不强制评审；摘要替代全量上下文；工具结果结构化；历史状态定期压缩；日志不进入用户界面。 第五种内耗是责任不清。用户最终看到错误结果时，到底是规划错、执行错、评审漏、工具错还是资料错？如果系统没有记录每个智能体的输入输出和工具调用，就无法定位。多智能体系统必须可审计。审计不是把所有内部对话展示给用户，而是在后台记录足够信息，方便团队改进和追责。 防内耗还有一个产品原则：不要把多智能体过程直接展示成最终体验。最终用户通常不关心几个Agent如何开会，他们关心结果是否可靠、下一步是什么、风险在哪里。除非用户明确需要调试视图，否则界面应该呈现清晰结论、依据、状态和行动按钮，而不是内部角色聊天记录。多智能体是实现方式，不应污染用户表达。 十、常见架构：主管、网络、层级和流水线 多智能体架构常见有四类：主管式、网络式、层级式和流水线式。主管式由一个Supervisor接收任务、分配给子Agent、汇总结果。它适合任务类型较多、需要路由和仲裁的场景。缺点是主管容易成为瓶颈，也可能因为上下文不足做错分配。主管必须有明确路由规则、状态视图和停止条件。 网络式让多个Agent互相交接，谁有能力谁继续。它适合开放探索和协作研究，但风险是对话路径难控，容易循环。网络式需要强状态管理和消息约束，否则每个Agent都可能把任务推给别人。LangGraph文档中提到多智能体可以通过supervisor、handoff等方式组织，本质上就是在控制谁拥有当前任务和下一步。 层级式适合大任务。高层Agent负责目标分解，中层Agent负责子任务管理，底层Agent负责工具执行。它像组织结构，适合复杂工程、内容生产和运维流程。缺点是层级越深，信息损耗越大。每一层都可能摘要错误、遗漏条件或扩大解释。因此层级式要有关键证据回溯机制，不能只传自然语言总结。 流水线式是最稳定的一类。任务按固定阶段流转，例如检索、抽取、生成、评审、修订、发布。每一阶段可以由一个智能体或模型节点负责，也可以混合程序工具。流水线不如开放多Agent灵活，但在生产里常常更可靠。很多看起来需要多智能体的任务，其实适合流水线加少量条件分支。 架构选择应从任务出发。客服问答通常适合检索加回答加核查流水线；复杂咨询适合讨论后收敛；代码修复适合执行加测试加评审闭环；企业流程适合主管式路由加权限隔离；开放研究适合网络式探索但必须有收敛器。不要先画多Agent架构图，再把任务硬塞进去。 架构还要考虑人机协同。多智能体不是把人完全排除。高风险动作、价值判断、资料缺失、权限变更、外部发布，都可能需要人工确认。系统应该知道何时停下来问人，而不是让Agent互相讨论到假装确定。人类介入点设计得好，多智能体反而更可靠。 十一、工程落地：从最小协作闭环开始 落地多智能体，不建议一上来做完整“AI公司”。更稳的方式是从最小协作闭环开始：一个执行Agent，一个评审Agent，一个明确验收。比如文档生成场景，先让作者Agent写，审校Agent查事实和重复，程序统计字数和引用，失败则回到作者修订。这个闭环能跑稳，再扩展检索Agent、结构Agent或发布Agent。 落地时要先定义状态对象。任务ID、当前阶段、输入资料、子任务状态、工具结果、文件版本、用户确认、失败原因、最终输出，都应该结构化。不要让多个Agent只靠聊天历史协作。状态对象越清楚，恢复、评审、审计和成本控制越容易。 第二步是定义消息协议。Agent之间传递的不是随意长文，而是结构化结果：目标、已完成、证据、开放问题、阻塞、建议下一步。自然语言可以存在，但关键字段要稳定。否则下游Agent要从上游散文里猜重点，错误会层层放大。 第三步是定义工具权限。每个Agent能用哪些工具，工具是只读还是写入，是否需要确认，失败如何处理，结果如何记录，都要明确。工具权限应该由系统强制，不只写在Prompt里。尤其是生产业务里，删除、提交、发送、支付、发布、审批都必须有硬边界。 第四步是定义质量门。哪些任务必须评审，哪些错误会阻断，哪些错误允许自动修复，哪些情况必须问用户。质量门应该和任务风险匹配。不要让所有任务都走最重流程，也不要让高风险任务一路自动通过。风险分级是多智能体系统能否可用的关键。 第五步是做真实评测。用真实用户问题、真实资料、真实工具和真实失败情况测试。不要只看演示对话。评测指标可以包括任务完成率、人工介入率、平均轮次、平均成本、阻断准确率、误报率、重复率、用户可采纳率。多智能体是否有用，最终要看这些指标，而不是看架构是否先进。 落地还要保持可替换。今天一个子任务用Agent，明天可能发现程序规则更稳；今天用主管式路由，明天可能改成固定流水线；今天用两个评审维度，明天可能合并。多智能体架构不要绑死业务。生产系统要允许根据数据收缩，而不是越做越复杂。 十二、判断清单：什么时候该用多智能体 可以用一组问题判断是否值得引入多智能体。第一，任务是否有天然分工？如果没有，先用单Agent。第二，子任务是否需要不同工具、资料或权限？如果没有，角色差异可能是假的。第三，是否存在高风险输出需要独立评审？如果有，评审Agent很可能值得。第四，是否能并行探索并明显节省时间？如果不能，并行协作收益有限。 第五，是否有清晰验收标准？没有验收，多智能体只会增加话语量。第六，是否有状态管理和失败恢复？没有状态，长任务会漂移。第七，是否有冲突仲裁规则？没有仲裁，分歧会被推给用户。第八，是否有成本预算？没有预算，协作很容易不可持续。第九，是否能从协作中记录可复用经验？如果不能，系统每次都从零开始讨论。 如果这些问题大多回答不上来，就不要急着上多智能体。可以先做单Agent加工具，加一个评审步骤，再加程序验收。很多生产场景在这个阶段已经足够。多智能体不是成熟度的象征，可靠交付才是。 如果这些问题答案清楚，多智能体会很有价值。它能让开放问题获得多视角，让高风险输出经过独立检查，让复杂任务按责任边界执行，让工具权限更可控，让长任务更容易恢复。它把模型从“一个会说话的助手”扩展成“一组受控协作的工作单元”。前提是系统知道每个工作单元为什么存在。 多智能体协作最好的形态，是用户感受不到混乱。用户看到的是清晰结论、可靠依据、必要确认和可执行下一步；后台则有分工、评审、状态和审计。协作不是表演，而是质量机制。什么时候它能提高质量，就用；什么时候它只增加内耗，就删掉。 十三、场景示例：知识库、代码、内容和业务流程 把原则放进具体场景，会更容易判断多智能体是否值得。第一个典型场景是企业知识库问答。用户问一个制度问题，系统先检索资料，再生成回答，再做事实核查。这里不一定需要很多智能体，但至少可以拆成回答者和核查者。回答者负责把资料转成用户能理解的结论，核查者负责检查每个关键断言是否有资料支撑，资料冲突时要求回答者说明冲突。这个协作有明确收益，因为知识库问答的主要风险就是“说得像真的但没有依据”。 知识库场景中，多智能体不应该表现成几个角色在前台聊天。用户不需要看“检索员认为”“审核员认为”。用户需要的是：根据哪些资料，可以得到什么结论；哪些问题资料没有覆盖；下一步应该找谁或做什么。后台协作越复杂，前台越要简洁。否则用户会把系统内部过程误解成结论本身。 第二个场景是代码修改。单Agent可以读代码、改代码、跑测试，但容易在修改范围和验收上出问题。更稳的协作是：定位Agent负责复现和根因，修改Agent负责最小补丁，测试Agent负责运行相关命令，评审Agent负责检查无关改动和回归风险。每个Agent不必都是完全独立模型，也可以是同一模型在不同任务契约下运行。关键是生成、执行和评审分开。 代码场景中，评审Agent必须看真实diff和测试结果，不能只听修改Agent总结。它要回答：问题是否真的被复现？改动是否只触及必要文件？测试是否覆盖失败路径？是否引入硬编码、权限绕过或兼容问题？如果评审发现阻断项，流程应该回到修改，而不是把风险写进最终说明后继续合并。多智能体的价值在于质量门，而不是多几段工程解释。 第三个场景是内容生产。长文、报告、白皮书和课程材料常常需要资料搜集、结构设计、正文写作、事实核查、编辑润色。多智能体在这里有用，因为各阶段目标不同。资料Agent追求来源质量和覆盖面，结构Agent追求论证顺序，作者Agent追求表达完整，核查Agent追求事实可回溯，编辑Agent追求重复减少和读者体验。它们的工作面不同，协作可以减少遗漏。 内容场景也很容易内耗。最常见问题是每个Agent都想重写全文，导致风格反复变化；或者评审Agent提出大量审美建议，让正文越改越散。解决办法是定义权限：核查Agent只指出事实问题，编辑Agent只改结构和重复，作者Agent负责最终统一表达。建议要分级，事实错误必须改，表达建议可选择。否则内容协作会从提高质量变成无限润色。 第四个场景是业务流程自动化。比如员工报销、采购申请、客户跟进、合同流转、售后处理。这里多智能体有用的原因不是讨论，而是权限和阶段。资料收集Agent可以帮助用户补齐信息，规则Agent检查是否符合政策，审批准备Agent生成申请材料，执行Agent在用户确认后提交系统，复核Agent检查提交状态。不同阶段有不同权限，不能让一个自由Agent从咨询一路自动提交。 业务流程场景最需要防止副作用。任何创建、发送、提交、取消、删除、支付、审批动作都应有确认和记录。多智能体可以把“建议”和“执行”隔离：建议Agent没有写权限，执行Agent只能在确认后调用工具，复核Agent读取结果但不能重复提交。这样即使建议有误，也不至于直接造成真实损失。 第五个场景是复杂研究和决策支持。比如技术选型、市场进入、供应商比较、AI模型选择。讨论型多智能体可以让不同角色提出互相冲突的目标：成本、性能、安全、可维护性、合规、用户体验。这里的价值是暴露取舍，而不是生成唯一答案。最终仍需要汇总者给出推荐和条件：如果预算优先，选什么；如果合规优先，选什么；如果上线时间优先，选什么。 这些场景说明，同样叫多智能体，实际目的完全不同。知识库重在核查，代码重在质量门，内容重在分阶段生产，业务流程重在权限隔离，研究决策重在多视角讨论。不能用同一套角色聊天模板解决所有问题。先识别主要风险，再设计协作结构，才是可落地路径。 十四、产品体验：用户看结果，系统管协作 多智能体系统容易犯一个产品错误：把后台协作过程当成卖点展示给用户。界面上出现多个AI头像、长篇角色对话、工具日志、内部状态、调度说明，看起来很透明，实际会增加理解负担。大多数最终用户不需要知道有几个智能体参与，他们只需要知道结果是否可信、依据是什么、接下来能做什么。 面向用户的表达应该统一。即使后台有多个Agent，最终输出也应该像一个专业团队给出的整理结果，而不是会议纪要。可以展示“结论”“依据”“风险”“下一步”“需要确认”，但不要展示“规划Agent说”“执行Agent说”“评审Agent反对”。内部角色名是实现细节，不是用户语言。 状态展示也要面向任务，而不是面向模型。用户关心“正在检索资料”“正在检查引用”“等待你确认提交”“测试未通过”，不关心“Agent A调用工具B返回JSON”。同样，错误提示应该说明用户能理解的原因：资料不足、权限不够、系统暂时不可用、需要补充字段、存在冲突。不要把栈信息、接口名、参数名、模型内部判断暴露给最终用户。 多智能体产品还要让用户能控制关键节点。讨论阶段可以让用户选择方案，执行前可以让用户确认动作，评审失败时可以让用户查看阻断原因，资料不足时可以让用户补充。用户控制点越清楚，系统越可信。相反，如果多个Agent在后台自动决定一切，用户只看到最终结果，就很难建立责任边界。 对团队内部工具，适度展示协作过程有价值。工程师可能需要看工具调用、状态图和评审日志；运营可能需要看失败原因和人工介入点；产品经理可能需要看任务完成率和成本。关键是区分调试视图和最终用户视图。调试信息属于后台，不应该混进正式回答。 多智能体体验还要避免“等待无反馈”。协作会增加耗时，如果用户只看到加载动画，会觉得系统卡住。更好的方式是展示阶段状态，但文字要克制：查找资料、整理答案、检查风险、准备结果。不要展示模型内部思考，也不要每一步都输出长解释。阶段状态帮助用户理解进度，最终结果负责交付价值。 最后，多智能体不应该成为复杂度借口。用户不会因为后台有五个Agent就原谅错误答案、重复内容或慢响应。产品体验的评判标准仍然是任务完成质量。协作只有在用户结果更好时才值得存在。 十五、组织方式：让多智能体像团队，不像群聊 多智能体系统如果要长期运行，需要像团队一样有职责、交接、验收和复盘，而不是像群聊一样谁都能说两句。每个智能体都应有稳定职责，不随任务临时漂移。一个负责检索的智能体，不应突然写最终结论；一个负责评审的智能体，不应擅自执行修改；一个负责发布的智能体，不应越过确认。 交接物要标准化。人类团队协作时会用需求文档、设计稿、代码diff、测试报告、审批单；智能体也需要类似结构。上游不要把散乱对话扔给下游，而要交付结构化结果：已完成事项、证据、未解决问题、建议下一步、风险等级。交接物越稳定，协作越不依赖模型临场理解。 验收权要明确。谁能宣布任务完成？是主管Agent、程序检查、评审Agent、用户，还是外部系统状态？不同任务答案不同。代码任务可能以测试和评审通过为准；业务提交以系统返回成功编号为准；内容任务以编辑和事实核查通过为准；高风险动作以用户确认和系统结果为准。没有验收权，多智能体会出现每个角色都完成但整体无人负责。 复盘机制同样重要。每次失败都应该记录：哪个阶段失败，失败原因是什么，是否可自动修复，是否需要改Prompt、工具、资料或权限。多智能体系统会产生更多日志，如果不复盘，只会堆积噪音。把失败转成模式库、评审清单和工具改进，协作系统才会越用越稳。 组织方式还要允许裁撤角色。某个Agent长期没有发现独立问题，或者输出总被其他步骤覆盖，就应该删除或合并。多智能体不是角色越多越成熟。成熟系统会根据数据缩减无用环节，把复杂度留给真正有风险的地方。 从这个角度看，多智能体协作不是“AI开会”，而是任务系统。它需要分工、协议、权限、状态、验收、复盘。缺少这些，多个智能体只是在同一个不确定空间里互相放大不确定性；具备这些，它们才能像一个受控团队一样处理复杂工作。 参考资料 Anthropic Engineering: Building Effective Agents, https://www.anthropic.com/engineering/building-effective-agents LangGraph Docs: Multi-Agent Systems, https://langchain-ai.github.io/langgraph/concepts/multi_agent/ OpenAI Agents SDK Docs: Agents, Handoffs, Guardrails and Tracing, https://openai.github.io/openai-agents-python/ Microsoft AutoGen Documentation, https://microsoft.github.io/autogen/ Microsoft AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework, https://arxiv.org/abs/2308.08155 CrewAI Documentation, https://docs.crewai.com/ CAMEL: Communicative Agents for Mind Exploration of Large Language Model Society, https://arxiv.org/abs/2303.17760 MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, https://arxiv.org/abs/2308.00352 ChatDev: Communicative Agents for Software Development, https://arxiv.org/abs/2307.07924 Multi-Agent Debate Improves Reasoning in Large Language Models, https://arxiv.org/abs/2305.14325 ReAct: Synergizing Reasoning and Acting in Language Models, https://arxiv.org/abs/2210.03629 AgentBench: Evaluating LLMs as Agents, https://arxiv.org/abs/2308.03688 SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, https://arxiv.org/abs/2310.06770 Voyager: An Open-Ended Embodied Agent with Large Language Models, https://arxiv.org/abs/2305.16291

AI Agent 最容易给人一种错觉：只要模型足够强，给它一个目标，它就会自己规划、自己调用工具、自己修复错误、自己完成任务。演示时，这种感觉尤其强。用户说“帮我调研竞品并写报告”，Agent 搜索网页、整理要点、生成文档；用户说“帮我修这个 bug”，Agent 读代码、改文件、跑测试；用户说“帮我订一套旅行计划”，Agent 查信息、比较价格、列出行程。看起来像一个真正能干活的助手。 但到了真实产品和真实工作流里，Agent 很容易烂尾。它开始时很积极，中间做了很多动作，最后却停在一个半成品：报告有结构但证据不完整，代码改了一半但测试没跑通，表单填了一部分但没有提交，工单分析了原因但没有给可执行结论，工具调用失败后换了几个方向又绕回原点。表面看是模型不够聪明， deeper 的原因通常是系统没有把任务边界、状态、工具和验收设计清楚。 Agent 烂尾不是一个单点问题。它往往来自四类缺口：目标没有被拆成可完成任务，状态没有被可靠保存和更新，工具能力和现实环境之间有缝，验收标准没有变成可执行检查。模型可以推理，可以写计划，可以调用工具，但它不能凭空知道“做到什么算完成”，也不能替系统弥补权限、幂等、回滚、错误处理和人工确认的缺失。真正生产级的 Agent，不是一个长提示词加一堆工具，而是一套可恢复、可验证、可审计的任务执行系统。 一、Agent不是聊天机器人加工具列表 聊天机器人回答问题，主要目标是生成一段有帮助的文本。Agent 执行任务，目标是改变某种状态：文件被修改，订单被创建，报告被交付，数据被分析，客户被跟进，代码通过测试，知识库被更新。这个差别决定了 Agent 不能只按对话质量来设计。它要面对现实世界里的状态变化、权限边界、失败重试、用户确认和最终验收。 ReAct 论文把 reasoning 和 acting 结合起来，让模型一边思考一边行动，通过工具观察外部环境，再根据观察继续推理。Toolformer 讨论模型如何学习使用工具。后来的 WebArena、AgentBench、GAIA、SWE-bench 等评测进一步把 Agent 放进更真实的环境：网页、工具、软件仓库、复杂问题和多步任务。它们共同说明一个事实：Agent 能不能完成事，不只取决于模型语言能力，还取决于它如何和环境互动。 很多产品失败，是因为把 Agent 当成“会调用工具的聊天框”。系统给模型一堆工具说明，然后希望模型自己决定何时用、怎么用、用完怎么判断结果。这样可以做演示，但很难做生产。真实工具有权限、参数、速率限制、异常、并发冲突和副作用。模型如果没有明确任务状态和验收标准，很容易在“继续查一点”“再试一次”“重新总结一下”之间循环。 Agent 的核心不是自由，而是受控自治。它需要在明确边界内自主处理细节，在高风险动作前请求确认，在失败时保存现场，在完成时给出可验证结果。Anthropic 在关于有效 Agent 的文章中强调，很多场景中工作流和 Agent 应该区分：如果任务路径清楚，工作流更可靠；如果路径需要动态决策，Agent 才有价值。这个判断很关键，因为不是所有自动化都应该交给开放式 Agent。 所以，设计 Agent 的第一步不是写系统提示词，而是判断任务属于哪一类。固定流程适合 workflow，开放探索适合 Agent，人机协同适合半自动流程。把所有事情都包装成 Agent，会让简单任务变复杂，也会让复杂任务缺少控制。 二、烂尾的第一类原因：任务边界太虚 用户经常用自然语言描述目标：“帮我研究一下”“帮我优化一下”“帮我做完这个”“帮我看看哪里有问题”。人能从上下文里追问、确认、判断范围，Agent 如果没有边界管理，就会把这些话当作开放任务开始执行。开放任务最大的问题是没有明确终点。研究到什么深度算够？优化到什么指标算好？做完包含哪些文件、哪些测试、哪些提交？看看问题后要不要修？没有边界，Agent 只能用自己的猜测停下来。 任务边界至少包含五件事：输入范围、允许动作、完成物、质量标准和退出条件。输入范围说明 Agent 应该看哪些文件、哪些数据、哪些网页，哪些内容不要碰。允许动作说明它能读、能写、能调用、能提交、能删除还是只能建议。完成物说明最终要交付什么，是文档、代码、配置、表格、工单结论还是操作记录。质量标准说明结果要满足什么约束。退出条件说明什么时候可以停止，什么时候必须追问，什么时候必须交给人。 烂尾常发生在“目标很大但没有拆解”的任务里。比如“帮我重构这个模块”包含理解现有行为、识别边界、制定方案、改代码、迁移调用、写测试、跑回归、处理兼容、更新文档。Agent 如果只看到一句目标，可能先改一个明显文件，然后发现影响更大，接着继续读更多文件，最后上下文越来越乱。正确做法是把大任务拆成可验收阶段：先输出影响分析，再确认范围，再改最小闭环，再跑测试，再处理边界。 边界虚还会导致过度执行。用户只是想要分析，Agent 却直接改文件；用户只想改一个页面，Agent 顺手重构全局样式；用户想要草稿，Agent 却调用外部系统发送消息。Agent 的“积极”在生产里可能是风险。系统需要把动作分级：只读动作可以自动执行，低风险写入可以在沙盒里执行，高风险写入必须确认，不可逆动作必须有预览和回滚。 任务边界也要处理“不做什么”。很多提示词只写要做的事，不写禁区。生产任务里，禁区同样重要：不要修改无关文件，不要使用未授权数据，不要猜测缺失信息，不要提交未经测试的代码，不要把系统后台信息展示给用户，不要在证据不足时给确定结论。这些不是道德口号，而是验收条件。 边界管理最实用的形态，是让 Agent 在开始前生成任务契约。契约不需要冗长，但要明确：目标、范围、步骤、交付物、需要用户确认的点、验收方式。对简单任务，契约可以自动生成并立即执行；对复杂或高风险任务，应先让用户确认。这样做不是降低智能，而是让智能有目标。 三、烂尾的第二类原因：状态没有被当成一等对象 Agent 执行任务时，状态比文本更重要。它已经读过哪些文件，做过哪些判断，调用过哪些工具，哪些步骤成功，哪些失败，用户确认了什么，当前阻塞在哪里，下一步是什么，这些都属于状态。如果状态只存在模型上下文里，就很脆弱。上下文会变长，会被截断，会被压缩，会混入旧信息。模型一旦忘记或误读状态，就会重复劳动、漏步骤或错误收尾。 长任务尤其依赖状态。一次代码修复可能经历读取报错、定位模块、修改文件、跑测试、发现新错误、二次修改、再跑测试、总结风险。一次研究任务可能经历搜索资料、筛选来源、记录引用、比较观点、写作、事实检查、修订。每一步都产生中间结果。没有结构化状态，Agent 很容易在后半程丢失前面做过的决定。 LangGraph 的 persistence 和 checkpoint 设计之所以重要，是因为它把 Agent 执行过程中的状态保存下来，支持从中断点恢复、人工介入和长期运行。生产 Agent 需要类似能力。浏览器崩了、工具超时了、用户离开了、模型请求失败了，任务不应该从头开始，也不应该忘记已经执行的副作用。可恢复执行是 Agent 从演示走向生产的分水岭。 状态还要区分事实、假设和计划。很多 Agent 烂尾，是因为把计划当事实。模型说“接下来我会运行测试”，并不等于测试已经运行；模型说“问题可能在缓存”，并不等于根因确认；模型说“已经修复”，如果没有执行验证，就只是声明。状态系统应记录每一步的证据：工具返回、文件 diff、测试结果、网页截图、用户确认、外部接口响应。 状态也要处理版本。Agent 读到的文件可能被用户或其他进程修改，网页内容可能变化，数据库记录可能更新，工单状态可能被同事处理。如果 Agent 用旧状态继续行动，就会覆盖别人工作或输出过期结论。生产系统需要在关键写入前检查版本、时间戳或 ETag，发现冲突时停下来而不是盲写。 还有一种常见烂尾来自多目标状态混杂。用户先让 Agent 查资料，后面又让它写文章，再让它顺手改标题。如果系统没有把当前任务和历史任务分开，模型会把旧目标、旧约束和新要求混在一起。多轮 Agent 应该维护任务栈或任务记录，把当前目标、已完成事项和开放问题清楚分离。 状态设计的原则很简单：重要信息不要只放在自然语言对话里。任务 ID、阶段、步骤、工具调用、文件改动、外部副作用、用户确认、阻塞原因、验收结果，都应该结构化记录。模型可以阅读这些状态，也可以更新这些状态，但不能把状态完全托付给一次上下文窗口。 四、烂尾的第三类原因：工具只是“能调用”，不是“能完成” 很多 Agent 系统把工具接入当作完成了一半：有搜索工具、浏览器工具、文件工具、数据库工具、邮件工具、日历工具、代码执行工具。实际上，工具能调用不等于工具能支撑任务完成。工具如果没有清晰输入输出、没有错误语义、没有幂等设计、没有权限控制、没有结果校验，模型调用得越多，风险越大。 一个好工具应该像面向 Agent 的产品接口，而不是把内部 API 原样暴露给模型。它的名称要表达动作，参数要少而清晰，返回结果要面向任务，错误要可恢复。比如搜索工具不应该只返回一大段 HTML，而应返回标题、链接、发布时间、摘要、来源可信度和可继续打开的句柄。数据库工具不应该把所有字段裸露出来，而应返回任务相关字段和权限范围。代码工具不应该只说“失败”，而应返回命令、退出码、关键错误和下一步建议。 工具烂尾常见于错误处理。模型调用工具失败后，如果错误信息模糊，它可能反复尝试同一个错误参数，或者换一个无关方向。工具应该把错误分成参数错误、权限错误、资源不存在、网络超时、速率限制、冲突、不可逆风险等类型，并告诉 Agent 哪些错误可以重试，哪些必须修改输入，哪些需要用户授权，哪些应该停止。 工具还要有幂等性。Agent 常常会因为不确定、超时或上下文恢复而重复调用工具。如果工具是“创建订单”“发送邮件”“删除文件”“提交审批”这种有副作用的动作，重复调用可能造成真实损失。生产工具应支持 idempotency key、预演模式、确认步骤和操作记录。模型不应靠记忆来避免重复副作用，系统要从工具层防住。 工具权限也不能交给提示词。不能只在系统提示词里写“不要访问无权限数据”。工具层必须根据用户身份、任务上下文和业务规则做权限判断。Agent 看到的工具应该是当前用户可用的工具，工具返回的内容应该是当前用户可见的内容。否则模型一次错误调用就可能越权。 工具结果要可验证。搜索结果要能打开来源，文件修改要能展示 diff，代码执行要能返回测试输出，业务操作要有记录编号，数据分析要有查询和计算过程。Agent 最终回答“我已经完成”时，应该能附带证据，而不是只给自然语言承诺。 工具设计还有一个容易忽略的问题：粒度。工具太细，Agent 需要做大量低层决策，容易迷路；工具太粗，Agent 看不到关键过程，无法修复失败。合理做法是为常见高价值任务提供任务级工具，同时保留必要的低层工具用于诊断。例如“运行项目测试并摘要失败”比裸 shell 更适合作为常用工具，“读取指定文件片段”比一次性暴露整个仓库更安全。 五、烂尾的第四类原因：验收没有自动化 Agent 最后一步最容易出问题。它做了很多动作后，需要判断是否完成。没有验收标准时，模型会用语言收尾：“已完成”“问题已修复”“报告如下”“可以上线”。这些话不等于结果有效。生产系统里，完成必须有证据。 验收要尽量靠外部事实。代码任务要跑测试、类型检查、lint 或至少执行复现用例；RAG 答案要检查引用是否存在、关键事实是否被证据支持；数据任务要校验行数、公式、异常值和可复算性；表单任务要确认提交成功编号；网页操作要有页面状态或截图；文档任务要检查字数、结构、引用和重复段落。能程序化检查的，不要交给模型自评。 没有自动验收，Agent 很容易“看起来完成”。比如它修了一个函数，但没跑测试；它写了一篇调研报告，但引用来源只有标题没有链接；它整理了表格，但数值没有对齐原始数据；它完成了浏览器操作，但页面其实卡在登录页；它生成了计划，但没有任何下一步执行。用户看到完整文字，容易误以为任务完成，直到真正使用时发现半成品。 验收还要覆盖负面条件。不是只检查有没有输出，还要检查有没有触碰禁区。代码任务要看是否修改无关文件、是否引入敏感信息、是否删除用户改动；业务操作要看是否越权、是否重复提交、是否跳过审批；文档写作要看是否出现面向系统维护者的旁白、无来源断言、过期信息；客服任务要看是否承诺不能承诺的内容。 Agent 的验收可以分层。第一层是硬检查，程序可以确定通过或失败。第二层是模型评审，适合开放内容质量。第三层是人工确认，适合高风险动作。不要让所有任务都等人工，也不要让所有任务都自动通过。风险越高，验收越严格。 验收失败后的处理也很重要。很多 Agent 烂尾不是因为第一次失败，而是失败后不知道怎么恢复。测试失败后要读取关键错误并尝试最小修复；引用缺失后要回到资料检索；权限不足后要请求授权；信息不足后要向用户追问；超过重试次数后要交付当前状态和明确阻塞原因。失败恢复应该是流程的一部分，而不是模型临场发挥。 一个实用规则是：不要允许 Agent 只用自然语言宣布完成。它必须提供完成物和验收证据。证据可以是测试输出、链接、文件路径、操作编号、引用清单、截图、差异摘要或人工确认记录。没有证据，就只能叫“草稿”或“建议”，不能叫完成。 六、长上下文不是状态管理 很多人以为上下文窗口越来越长，Agent 烂尾问题会自然缓解。长上下文确实有帮助，模型可以看到更多历史、更多文件、更多资料。但长上下文不是状态管理。把所有对话、工具结果、网页内容和文件片段都塞进窗口，只会把任务历史变成一个难以检索的仓库。 长上下文有三个问题。第一，重要信息可能被淹没。Lost in the Middle 等研究提醒，模型不总能均匀使用长输入中的信息。第二，旧信息会和新信息冲突。任务中途用户改了目标，旧计划仍在上下文里，模型可能混用。第三，成本和延迟会上升。Agent 每一步都带着庞大历史，会让简单动作变慢。 生产 Agent 应该把上下文和状态分工。上下文提供当前推理所需材料，状态保存任务事实和执行进度。模型每一步不必看到全部原始历史，只需要看到当前目标、相关证据、已确认决策、待办事项和最近失败。完整日志可以留存供追溯，但不应该每次都塞给模型。 摘要也不能随便做。普通对话摘要可能丢掉关键约束，例如“不要修改某个文件”“这个测试失败可忽略”“用户已经确认方案 B”。Agent 状态摘要应该结构化：目标、范围、已完成、未完成、阻塞、用户确认、外部副作用、风险和下一步。摘要本身也要可更新、可审计。 如果任务跨越多次会话，状态更重要。用户隔天回来问“继续昨天那个任务”，Agent 不能只靠聊天记录猜。它需要知道昨天的任务 ID、最新文件版本、已跑过哪些测试、哪些问题未解决、用户最后确认了什么。没有持久状态，跨会话 Agent 基本只能重新开始。 长上下文的正确用法，是在需要时调取相关材料，而不是作为一切记忆的垃圾桶。它适合阅读长文档、比较资料、理解代码片段，但不适合替代任务数据库、事件日志、检查点和权限系统。 七、计划不是执行，执行不是完成 Agent 很擅长写计划，这也是它最容易欺骗人的地方。一个结构清晰的计划看起来像进展，但计划本身没有改变现实状态。用户要的是代码修好、资料查完、文件生成、问题关闭，不是一个漂亮流程图。Agent 系统必须区分计划、执行和完成。 计划阶段应该回答“打算怎么做”。它可以包含任务拆解、风险点、需要工具、需要确认的动作。执行阶段应该产生外部证据，例如读取文件、调用接口、写入文档、运行命令。完成阶段应该通过验收，并把结果交付给用户。三者混在一起时，Agent 会出现“写了很多步骤，但没真正做”的烂尾。 执行也不等于完成。运行了搜索，不等于完成调研；修改了代码，不等于修复 bug；调用了提交接口，不等于业务成功；生成了文档，不等于文档可用。每个执行动作后都要判断它是否推动任务接近验收。如果动作没有产生有效证据，就只是活动，不是进展。 生产系统可以用状态机约束这一点。任务从待澄清、已确认、执行中、待验收、已完成、已阻塞、已取消等状态流转。模型可以建议状态变化，但关键状态变化需要证据。比如从执行中进入已完成，必须有验收结果；从待澄清进入执行中，必须有足够任务边界；从待确认进入执行中，必须有用户确认。 这种状态机并不会削弱 Agent。相反，它让 Agent 有更清晰的行动空间。模型负责处理不确定性和复杂推理，系统负责确保每一步有位置、有记录、有退出条件。没有状态机，Agent 看起来更自由，但也更容易游荡。 八、人类介入不是失败，而是产品能力 很多 Agent 设计把人工介入当作失败路径，仿佛真正智能就应该全自动。生产场景恰恰相反：恰当的人类介入是可靠性的组成部分。高风险动作、信息不足、权限缺失、价值判断、不可逆操作，都应该让人确认。一个知道何时停下来问人的 Agent，比一个自信乱做的 Agent 更可用。 人类介入要设计得具体。不要只弹一句“需要确认吗”。应该展示将要执行的动作、影响范围、可选方案、风险和回滚方式。比如代码 Agent 在大范围修改前展示文件列表和改动意图；邮件 Agent 在发送前展示收件人、主题、正文和附件；业务 Agent 在提交审批前展示字段差异和依据。用户确认的是具体动作，不是抽象信任。 人工介入也要进入状态。用户确认了什么、拒绝了什么、修改了什么，都应被记录。否则下一步模型可能忘记用户刚刚否定的方案。人类反馈不是聊天噪声，而是任务状态的一部分。 还要避免把所有问题都推给用户。低风险、可验证、可回滚的动作应该自动完成。频繁确认会让 Agent 失去效率，用户也会机械点击。关键是风险分级：只读自动，草稿自动，可回滚写入可批量确认，不可逆和外部影响动作必须确认。 Anthropic 关于有效 Agent 的观点中，有一个重要判断：能用简单 workflow 解决的问题，就不要强迫模型每一步都自由决策。人类介入也类似。需要人判断的地方让人判断，不需要人判断的地方系统自动推进。好的 Agent 产品不是“全自动”或“全人工”，而是在正确位置切换控制权。 九、Agent评测必须评任务完成率 Agent 的评测不能停留在回答质量。它要看任务完成率。WebArena 把 Agent 放进真实风格的网站环境中完成任务，SWE-bench 用真实 GitHub issue 和仓库测试模型解决软件问题，GAIA 强调需要推理、工具使用和多步骤能力的问题。这些评测共同说明：Agent 的关键指标是能否在环境中完成目标，而不是单轮文本是否好看。 任务完成率也要拆分。一个任务失败，可能是理解错目标，可能是工具调用错，可能是状态丢失，可能是权限不足，可能是验收没过，可能是超时，也可能是模型在某一步推理失败。只记录“失败”没有改进价值。生产 Agent 应该记录失败阶段和失败原因。 Agent 评测集要包含真实长尾。简单任务只会证明演示可行。真正有用的评测应该包括模糊需求、缺失信息、工具报错、页面变化、文件冲突、权限限制、部分成功、需要追问、需要回滚等情况。Agent 是否能优雅处理这些情况，比顺风任务更能说明生产能力。 还要看效率。一个 Agent 最终完成任务，但用了二十次无效搜索、十次重复命令、三次错误写入，生产上也不一定可接受。评测要记录步骤数、工具调用数、成本、耗时、重试次数和人工介入次数。任务完成率高但成本失控，不能算好系统。 安全评测也不可少。Agent 有工具和副作用，风险高于普通聊天。它可能越权读取数据、泄露隐私、执行危险命令、发送错误消息、删除文件、重复提交。安全评测要覆盖权限、注入攻击、工具结果污染、外部网页诱导、敏感信息处理和不可逆操作确认。 最后，Agent 评测应该接近真实产品路径。只用模拟工具和理想 API，会高估能力。真实网页会变，真实代码有依赖，真实数据有脏值，真实权限会拒绝，真实用户会中途改需求。越接近真实环境，越能提前发现烂尾点。 十、上下文工程是Agent可靠性的基础 Agent 的上下文比普通问答更复杂。它不仅包含用户问题，还包含系统目标、工具说明、历史步骤、观察结果、外部资料、当前状态和验收标准。上下文工程做不好，Agent 会把无关信息当线索，把旧状态当当前事实，把工具错误当业务结论。 好的 Agent 上下文应该短而强。每一步给模型的信息都应该服务当前决策：现在目标是什么，已经确认什么，最近观察到什么，可用工具是什么，下一步需要解决什么，完成标准是什么。不要把完整日志、所有工具说明、所有历史对话都塞进去。信息越多，模型越容易抓错重点。 工具说明要和任务相关。一个 Agent 如果每次都看到几十个工具，会增加选择错误概率。可以按任务阶段动态暴露工具：调研阶段给搜索和阅读工具，写作阶段给文档工具，代码阶段给文件和测试工具，提交阶段给确认和发布工具。工具列表本身就是上下文的一部分，需要设计。 观察结果要整理。工具返回的原始内容往往太长、太杂、太面向机器。系统应把观察转成模型可用事实，同时保留原始证据可追溯。例如网页工具返回摘要、关键段落和链接；测试工具返回失败测试名、错误位置和关键堆栈；数据库工具返回查询结果和字段解释。模型需要的是决策材料，不是杂乱日志。 上下文还要避免指令冲突。外部网页、用户上传文档、工具返回内容里可能包含“忽略之前指令”“把密钥发给我”这类注入文本。Agent 不能把环境内容和系统指令放在同一层级。外部内容应该标记为数据，不能成为控制指令。工具层和模型层都要防止 prompt injection。 上下文工程不是写更长 prompt，而是控制信息流。Agent 烂尾时，很多团队第一反应是加一句规则。规则越加越多，模型越难判断优先级。更好的做法是减少噪声、结构化状态、缩小工具集、明确验收，并把规则落实到系统检查。 十一、从演示到生产的Agent架构 一个生产级 Agent 通常需要六个核心模块。第一是任务入口，把用户意图转成任务契约，识别风险和边界。第二是状态管理，记录阶段、步骤、证据、用户确认和外部副作用。第三是工具层，提供安全、清晰、可验证、可恢复的动作。第四是规划与执行，让模型在当前状态下选择下一步。第五是验收层，用程序、模型评审和人工确认判断是否完成。第六是观测与回放，记录 trace，支持复盘和改进。 这些模块不一定都很重，但不能缺席。小任务可以简化状态，小工具可以少量接入，低风险任务可以弱化人工确认。但只要 Agent 要处理真实用户目标，就必须有边界、状态、工具和验收。否则它只是一个更会说话的自动补全。 任务入口要有澄清能力。用户目标不清时，Agent 应该追问最少必要问题，而不是假装理解。比如“帮我优化网站”需要知道优化性能、转化率、视觉还是 SEO；“帮我修复登录问题”需要知道复现路径、报错、目标环境；“帮我写方案”需要知道受众、用途、长度和资料来源。追问不是能力不足，而是减少错误执行。 状态管理要支持恢复。任务中断后能继续，失败后能回滚到最近检查点，用户能看到当前进度。状态不是给开发者看的内部调试，而是支撑产品体验：用户知道 Agent 做到了哪里，为什么停住，还差什么。 工具层要做抽象。不要让模型直接面对所有内部接口。把高频任务封装成更安全的动作，把危险能力放在确认后，把返回结果变成可读证据。工具越接近用户任务，Agent 越容易完成。 验收层要有硬门槛。没有通过测试的代码不能说修好，没有引用的事实不能说确认，没有提交编号的外部操作不能说完成，没有用户确认的高风险动作不能执行。硬门槛会让 Agent 少说大话，多交证据。 观测与回放决定长期改进。每次失败都应该能看到任务契约、状态变化、工具调用、模型决策、验收结果和用户反馈。没有这些记录，团队只能看最终回答猜原因。Agent 系统越复杂，trace 越重要。 十二、不同场景的烂尾点 代码 Agent 常见烂尾是改了代码但不跑测试，跑了测试但不理解失败，修了一个文件却破坏另一个模块，或者在大型仓库里读太多无关文件。解决关键是限定修改范围、维护文件状态、运行真实测试、保留 diff、识别用户未授权改动，并在测试失败时做有证据的最小修复。 研究写作 Agent 常见烂尾是资料堆砌、引用不完整、来源质量不一、结论没有区分事实和观点。解决关键是优先权威来源，记录链接和发布时间，按问题组织证据，写作后做事实检查和重复检查。长文不是完成，来源和结构才是完成条件。 浏览器操作 Agent 常见烂尾是页面状态识别错误、弹窗或登录阻塞、表单填错、提交前没有复核、提交后没有确认编号。解决关键是让每一步读取页面状态，关键动作前截图或摘要，提交前展示字段，提交后确认成功页面或记录号。 客服 Agent 常见烂尾是解释很多但没有解决问题，或者在资料不足时给确定承诺。解决关键是把用户问题分类、检索最新政策、确认用户身份和权限、给出明确下一步，无法解决时准确转人工并携带上下文。 数据分析 Agent 常见烂尾是生成图表但计算不可复现，或者结论没有说明口径。解决关键是保存查询、清洗步骤、指标定义、异常处理和图表来源。分析结果要能被复算，否则只是文本。 企业流程 Agent 常见烂尾是绕过审批、重复提交、字段填错或缺少操作记录。解决关键是权限校验、预演、幂等、确认、提交回执和审计日志。流程 Agent 的可靠性来自制度化动作，不是模型自觉。 十三、怎样减少烂尾 第一，把用户目标转成可验收任务。不要让 Agent 直接从一句模糊话开始行动。目标、范围、交付物、禁区和验收方式越清楚，烂尾越少。 第二，把状态结构化保存。每一步做了什么、得到什么证据、下一步是什么、哪些事未完成，都要记录。长上下文只能辅助，不能替代状态。 第三，重新设计工具，而不是裸接 API。工具要任务化、权限化、可恢复、可验证。错误信息要让 Agent 知道下一步该怎么办。 第四，设置硬验收。代码要测试，资料要引用，操作要回执，文档要检查，风险动作要确认。不要允许自然语言自证完成。 第五，限制行动空间。按任务阶段暴露工具，按风险等级控制权限，按范围限制文件和数据。自由不是越大越好，边界清楚才更可靠。 第六，让 Agent 会停。资料不足时追问，权限不足时请求授权，风险过高时等确认，超过重试次数时交付阻塞原因。会停是生产能力。 第七，用真实任务评测。不要只看演示问题。把历史失败、边界案例、工具异常、权限限制和长任务放进评测集，记录任务完成率、成本和失败原因。 第八，把失败变成资产。每次烂尾都要进入复盘：边界是否不清，状态是否丢失，工具是否误导，验收是否缺失。修复系统，而不是只给提示词再补一句。 十四、Agent可靠性的最终判断 一个 Agent 是否可靠，不看它能不能写出漂亮计划，也不看它能不能连续调用很多工具，而看它能不能在真实边界内持续完成任务。它应该知道目标，知道当前状态，知道能用什么工具，知道什么时候需要人，知道完成标准，知道失败后怎么恢复。缺少这些，模型越强，行动越多，烂尾和误操作的风险也越大。 未来模型会继续变强，工具调用会更自然，长上下文会更便宜，Agent 框架会更成熟。但生产问题不会因此消失。任务边界、状态、工具和验收是工程基本盘。强模型可以让 Agent 更聪明，不能替代产品和系统设计。 真正可用的 Agent，最后给用户的不是“我正在处理”“我建议你可以”“我已经尝试”，而是清楚的完成物、可检查的证据、必要的风险提示和下一步选择。能把事情做到这里，才不容易烂尾。 十五、把Agent拆成可运营的服务 Agent 如果只被看成一次模型调用，就很难运营。真实产品里的 Agent 更像一个服务：有入口，有队列，有状态，有权限，有日志，有失败处理，有用户反馈，有成本预算。服务化之后，团队才能回答一些关键问题：今天完成了多少任务，失败最多发生在哪一步，哪些工具最常超时，哪些用户问题最容易卡住，哪些任务成本过高，哪些输出需要人工复核。 运营 Agent 的第一件事，是定义任务类型。不要把所有请求都扔进同一个大 Agent。调研、写作、代码修复、数据分析、表单操作、客服处理、知识库问答，各自需要不同工具、状态和验收。任务类型越清楚，系统越容易选择合适流程。低风险高频任务可以自动化更多，高风险低频任务可以保留更多人工确认。 第二件事，是设计任务队列。很多 Agent 任务不是即时完成的。长文档分析、代码修改、批量数据处理、网页调研都可能需要几十秒到几分钟。用户不应该盯着一个聊天气泡等待，也不应该在刷新页面后丢失进度。任务队列可以让 Agent 后台执行、保存进度、失败重试、通知用户，并支持暂停、取消和继续。 第三件事，是做成本控制。Agent 比普通聊天更容易烧成本，因为它会多轮思考、多次检索、多次工具调用、多次验证。没有预算，它可能为了一个低价值问题消耗大量 token 和外部调用。系统应该按任务设置预算：最大步骤数、最大工具调用数、最大搜索次数、最大执行时间、最大重试次数。预算用完后，Agent 应该总结已完成内容和阻塞原因，而不是无限循环。 第四件事，是收集用户反馈。用户说“有用”或“没用”只是粗粒度反馈，更有价值的是他们修改了哪里、采纳了哪些建议、拒绝了哪个动作、为什么转人工。反馈应该进入评测集和任务策略。Agent 产品不是一次设计完成，而是在真实任务中不断学习边界。 第五件事，是提供透明进度。透明不是展示模型内心独白，而是告诉用户当前处于哪个阶段：正在读取资料、正在核对证据、正在运行测试、等待确认、验收失败、需要补充信息。用户看到可靠进度，就能理解等待原因，也能在关键点介入。没有进度的 Agent，一旦耗时变长，用户会以为它卡住。 十六、Agent烂尾和组织流程有关 很多 Agent 烂尾并不完全是技术问题，而是组织没有把流程说清楚。企业里大量任务依赖隐性规则：谁能批准，哪个文件是准的，哪些字段必须填，哪些异常要升级，哪些操作不能在周五做，哪些客户需要特殊处理。人类员工通过培训和经验掌握这些规则，Agent 如果没有被明确告知，就只能猜。 因此，上 Agent 前要梳理流程。不是把现有制度全文塞进 prompt，而是把流程转成可执行规则、工具权限和验收条件。比如报销助手需要知道费用类型、票据要求、审批链、金额阈值和例外处理；招聘助手需要知道岗位要求、候选人隐私、面试阶段和拒信模板；运维助手需要知道变更窗口、回滚方案、审批人和告警级别。 流程不清时，Agent 会暴露组织混乱。一个部门说按 A 规则，另一个部门说按 B 规则；文档里写一种做法，实际执行又是另一种；系统字段叫法和业务人员叫法不一致。模型不是流程治理工具，它只能把混乱放大。真正要让 Agent 完成任务，先要把关键流程标准化。 组织流程还决定人工介入点。谁能批准高风险动作，谁能判断专业争议，谁负责处理失败任务，谁维护知识库，谁复盘事故。如果这些责任没有归属，Agent 遇到边界问题就会停在那里。生产 Agent 需要的不只是模型能力，还有明确的运营责任。 流程变化也要进入版本管理。业务规则今天改了，Agent 明天还按旧规则执行，就是事故。知识库文档、工具权限、任务模板、验收规则都应该有版本和发布时间。Agent 生成结论时，应使用当前有效版本，并能说明依据。对高风险业务，过期规则比没有规则更危险。 十七、不要让提示词承担全部责任 Agent 烂尾后，很多团队第一反应是改提示词：加一句“必须完成任务”，加一句“不要放弃”，加一句“失败后继续尝试”，加一句“最终必须验收”。这些提示词有时能改善表现，但不能解决结构问题。提示词能影响模型行为，不能提供缺失的状态、权限、工具语义和验收机制。 “必须完成任务”如果没有退出条件，会鼓励模型硬撑。资料不足时它可能编造，权限不足时它可能绕路，测试失败时它可能忽略。生产系统更需要“在满足验收条件时完成，在证据不足时停止并说明，在高风险动作前请求确认”。这比单纯要求坚持更可靠。 “失败后继续尝试”如果没有失败分类，会导致重复。网络超时可以重试，参数错误应该修参数，权限错误应该请求授权，业务冲突应该交给人，不可逆风险应该停止。提示词很难稳定完成这些判断，工具层应该返回明确错误类型，状态机应该决定下一步。 “最终必须验收”如果没有验收工具，也只是口号。模型不能自己证明测试通过，必须真的运行测试；不能自己证明引用正确，必须能定位来源；不能自己证明提交成功，必须拿到回执。验收是系统能力，不是语气要求。 好的提示词仍然重要。它负责让模型理解角色、目标、优先级和表达方式。但提示词应该站在系统设计之上，而不是替代系统设计。边界靠任务契约，状态靠持久化，工具靠接口设计，验收靠检查器，提示词负责把这些信息组织给模型使用。 十八、一个最小可行的防烂尾清单 做一个不容易烂尾的 Agent，不一定一开始就搭复杂平台。可以从最小清单开始。第一，每个任务进入执行前，都有目标、范围、交付物和验收方式。第二，每个任务都有状态记录，至少包含已完成、待处理、阻塞和证据。第三，每个工具都有清晰错误类型和可读返回。第四，每个高风险动作前都有确认。第五，每个完成声明都有外部证据。 第六，给任务设置预算。最大步骤数、最大耗时和最大重试次数能防止无意义循环。第七，失败时输出阻塞原因，而不是编造完成。第八，把失败样本回收进评测。第九，定期查看任务日志，找出最常见烂尾点。第十，把常见成功路径固化成 workflow，把不确定部分留给 Agent。 这个清单的重点，是把“智能”落到可执行结构里。Agent 不需要每一步都自由发挥。很多成熟能力应该变成固定流程，例如检索后重排、写作后查重、代码修改后测试、提交前预览、失败后分类。模型负责处理复杂判断，流程负责保证基本可靠。 当最小清单跑通后，再逐步增强。增加更好的规划器、更多工具、更细权限、更强评测、更丰富人机协同、更长任务恢复。不要反过来先堆工具和模型，再补状态和验收。那样演示会很快，生产会很痛。 参考资料 ReAct: Synergizing Reasoning and Acting in Language Models: https://arxiv.org/abs/2210.03629 Toolformer: Language Models Can Teach Themselves to Use Tools: https://arxiv.org/abs/2302.04761 WebArena: A Realistic Web Environment for Building Autonomous Agents: https://arxiv.org/abs/2307.13854 SWE-bench: Can Language Models Resolve Real-World GitHub Issues?: https://arxiv.org/abs/2310.06770 GAIA: A Benchmark for General AI Assistants: https://arxiv.org/abs/2311.12983 AgentBench: Evaluating LLMs as Agents: https://arxiv.org/abs/2308.03688 Anthropic: Building Effective Agents: https://www.anthropic.com/engineering/building-effective-agents LangGraph Persistence Documentation: https://langchain-ai.github.io/langgraph/concepts/persistence/ OpenAI Agents SDK Documentation: https://openai.github.io/openai-agents-python/ Model Context Protocol Specification: https://modelcontextprotocol.io/specification

站点：localaihub.com 风格：社区实践帖 联网检索日期：2026-05-22 很多人第一次听到“蜂群协作”“多智能体团队”，会下意识觉得这像玄学：给几个大模型起名字，一个叫产品经理，一个叫工程师，一个叫评审官，然后它们在群聊里互相夸几句，最后生成一段看起来像方案的文本。这样的玩法确实不少，但它不是我们要讨论的多智能体协作。 真正有价值的多智能体团队，核心不是角色扮演，而是分工、校验和交付。分工解决“谁做什么”；校验解决“做得对不对”；交付解决“结果能不能被真实使用”。如果一个多智能体系统不能减少上下文混乱，不能降低错误率，不能留下可追踪证据，也不能产出更好的工件，那它只是把一个模型的问题拆成了多个模型的问题。 这篇社区实践帖想讲清楚一件事：蜂群协作不是魔法，也不是把 agent 数量堆起来，而是用工程方法组织一组会使用工具、会交换工件、会互相检查、会对结果负责的智能体。你可以把它理解成一个小型 AI 团队：有人调研，有人执行，有人测试，有人把关，有人把交付物整理到用户能用的状态。 一、先别急着上多智能体 在实践里，多智能体不是默认答案。很多任务用一个智能体加几件好工具就够了。比如查询订单、生成会议纪要、改一个配置、根据文档回答问题，这类任务如果拆成多个智能体，反而会增加通信成本和失败点。 什么时候应该考虑多智能体？通常有四种信号。 第一，任务跨度大。比如“调研一个技术方案并落地到代码”，既要查资料，又要读代码，又要改文件，又要跑测试，还要写说明。一个智能体能做，但上下文会很长，注意力容易散。 第二，任务需要独立校验。比如写长文、做财务分析、生成合同草案、规划生产变更。生成者和检查者最好不是同一个工作单元，否则它很容易为自己的错误找理由。 第三，工具权限不同。研究员可以联网，工程师可以改代码，发布员可以触发部署，审计员只能读日志。把这些权限放在同一个智能体身上，会让风险变大。 第四，专业视角不同。产品视角看用户目标，工程视角看实现约束，安全视角看权限边界，测试视角看失败路径。多视角并不是为了制造争论，而是为了减少单一视角的盲区。 如果没有这些信号，多智能体很可能只是增加复杂度。社区里很多失败案例，本质上都是“一个模型能做的事，硬拆成五个模型，然后没人负责最后交付”。 二、蜂群协作的最小可用模型 一个可落地的蜂群协作系统，至少有五个元素： 目标：团队最终要交付什么。 角色：每个智能体的职责和边界。 工件：角色之间传递的结构化结果。 校验：谁检查什么，按什么标准检查。 编排：什么时候并行，什么时候串行，什么时候停止。 “工件”是最容易被忽略的部分。很多多智能体系统让所有智能体共享一段聊天记录，看起来信息透明，实际很快变成噪声。真正的协作应该围绕工件进行：研究卡片、需求清单、修改计划、代码补丁、测试报告、风险清单、最终文档。聊天只是过程，工件才是交付物。 用写一篇技术教程举例，比较差的协作方式是： 研究员：我觉得可以写这些点。 作者：我来写。 评审：写得不错。 总结者：这是最终答案。 比较好的协作方式是： 研究员输出资料卡片：来源、链接、发布时间、关键结论、可信度。 架构员输出提纲：章节、读者目标、每章要解决的问题。 作者输出正文：只使用已确认资料，不虚构引用。 事实核查员输出问题清单：哪些说法缺来源，哪些需要改写。 编辑输出发布稿：去重、层级、标题、读者语气、参考资料。 差别就在于，后一种方式每一步都有可检查的中间成果。即使最后文章不完美，也能知道问题出在资料、结构、正文还是审核。 三、角色怎么分：按责任分，不按头衔分 多智能体角色不应该照搬公司组织架构。很多系统喜欢设置“CEO、CTO、产品经理、程序员、测试工程师”，但这些头衔如果没有工具权限和输出契约，就只是装饰。 更实用的分法是按责任分。 研究型角色负责降低未知。它的任务是查资料、找证据、比较方案、发现限制。它的输出不是“我觉得”，而是带来源的事实卡片。它应该优先使用官方文档、论文、项目文档、厂商说明、标准规范。研究型角色可以联网，但不应该直接改生产文件。 执行型角色负责改变世界。它可以写代码、改配置、生成文档、调用业务 API、创建工单。执行型角色必须有明确权限边界和回滚策略。它的输出不是“已经处理”，而是具体改了什么、改在哪里、验证了什么。 评审型角色负责找问题。它不需要重复完成任务，而是检查事实、逻辑、格式、安全、风险和可用性。评审型角色最怕变成礼貌评论员，所以必须给它硬标准：链接是否可达，测试是否通过，权限是否越界，用户目标是否满足。 协调型角色负责控制流程。它维护任务目标、分配子任务、合并工件、判断是否需要重试或询问用户。协调者不是老板，它更像调度器和状态机。它不能只会说“继续优化”，必须能决定“停止、交付、返工、升级确认”。 交付型角色负责把结果变成用户能用的形态。很多 AI 团队停在“内容已经生成”“代码已经改好”，但用户需要的是文件路径、部署地址、测试结果、操作说明、风险提示。交付型角色要把工程产物整理成最终状态。 一个简单任务不需要五种角色都出现。比如修改一个前端按钮，可能只需要执行者和评审者。一个复杂项目计划，可能需要研究、协调、执行、评审和交付全部参与。角色数量由任务复杂度决定，不由想象力决定。 四、协作模式一：主管加专家 “主管加专家”是最常见的多智能体模式。一个主管智能体接收用户目标，拆分任务，然后把子任务交给专家智能体。OpenAI Agents SDK 的 handoffs、LangGraph 的 supervisor、Google ADK 的 agent team 都支持这类模式。 这个模式适合边界比较清晰但步骤需要动态调整的任务。例如： 用户目标：把一个知识库问答功能改成真正能调用企业文档，并验证回答引用。 主管：拆成文档接入、检索链路、回答生成、引用验证、端到端测试。 后端专家：实现文档索引和检索接口。 AI 专家：调整回答链路和引用格式。 测试专家：构造问题并检查引用是否来自正确文档。 交付专家：汇总改动、测试结果和剩余风险。 主管模式的优势是灵活。用户不用知道任务应该拆成几块，主管可以根据执行结果调整下一步。如果检索接口已经存在，就跳过实现；如果测试发现召回错误，就把任务退回给后端专家。 主管模式的风险也明显。主管如果没有足够上下文，会分错任务；如果太相信专家，会把错误结果合并；如果没有预算控制，会无限循环。实践里需要给主管三个硬约束： 每次分配任务必须说明输入、输出和验收标准。 每个专家返回结果必须包含证据或明确失败原因。 主管只能在验收标准满足后合并结果。 主管不是“最聪明的人”，它是流程控制器。它的价值在于让任务状态清楚，而不是在所有专业问题上都亲自裁决。 五、协作模式二：流水线 流水线适合有固定阶段的任务。内容生产、数据清洗、报表生成、客服工单处理、发布检查，都很适合流水线。 以社区文章生产为例： 选题输入 -> 资料检索 -> 观点整理 -> 提纲生成 -> 初稿写作 -> 事实核查 -> 编辑润色 -> 发布检查 -> 输出文件 流水线的优点是稳定，每个阶段的输入输出都可以标准化。资料检索阶段必须输出链接和摘要；事实核查阶段必须输出问题清单；发布检查阶段必须输出字符数、链接数量、目标文件路径。 流水线的缺点是容易僵硬。如果资料不足，不能硬往下走；如果事实核查发现关键论点错误，不能只在末尾修几个字。好的流水线必须允许回退。例如事实核查失败时，回到资料检索；编辑发现结构混乱时，回到提纲；发布检查发现文件路径不对时，回到交付阶段。 LangGraph 这类图工作流适合表达这种回退和分支。相比让模型自由决定所有流程，图式编排能把稳定流程固定下来，让模型只处理需要判断的部分。生产系统里，稳定环节用代码，模糊判断用模型，这是更可靠的搭配。 六、协作模式三：并行生成加评审 有些任务没有唯一答案，比如产品方案、架构选型、营销文案、故障排查。此时可以让多个智能体并行给出方案，再由评审者比较。 并行不是为了制造更多文本，而是为了覆盖不同假设。比如架构选型可以分成： 方案 A：优先复用现有系统。 方案 B：优先长期扩展性。 方案 C：优先最低交付风险。 评审：比较成本、风险、迁移路径、验证难度。 这种模式很有用，但要防止两个问题。 第一个问题是“平均化”。评审者把三个方案糊成一个折中方案，最后失去重点。解决方法是要求评审输出明确取舍：推荐哪个，为什么，不选哪些，代价是什么。 第二个问题是“互相污染”。如果三个生成者共享彼此答案，可能都沿着同一个错误假设走。需要独立生成时，就让它们只共享任务目标，不共享中间答案。等到评审阶段再合并。 并行模式成本高，不适合所有任务。它适合高价值决策、模糊问题、创意问题和历史上容易出错的任务。 七、协作模式四：生成者与批判者 “生成者与批判者”是最容易落地的质量提升模式。一个智能体负责产出，另一个智能体负责挑错。它比完整多智能体团队轻，但效果通常明显。 关键在于批判者不能只说“很好，可以更具体”。它必须按清单检查： 事实：关键说法是否有来源。 完整性：用户要求是否全部覆盖。 一致性：前后是否矛盾。 可执行性：有没有具体步骤、路径、命令或交付物。 安全性：有没有越权、泄露、危险操作。 风格：是否符合目标站点或产品语言。 写作任务里，批判者可以检查是否原创、是否空泛、是否引用过度、是否标题层级混乱。代码任务里，批判者可以检查边界条件、测试缺口、回滚风险、用户体验。运维任务里，批判者可以检查是否误把健康检查当完整验收，是否漏掉真实用户路径。 批判者提出问题后，生成者必须修正。否则“评审”只是仪式。更进一步，可以要求批判者对修正后版本再次检查，直到剩余问题低于阈值或需要用户决策。 八、工具与权限：蜂群必须有边界 多智能体系统一旦接入真实工具，就必须认真处理权限。工具包括搜索、文件、数据库、浏览器、命令行、部署、支付、邮件、CRM、工单、机器人控制等。每个工具都可能造成真实影响。 实践里建议按权限分成四类： 只读工具：搜索、读取文档、查询数据库、查看日志。 草稿工具：生成邮件草稿、创建待审核工单、准备变更计划。 写入工具：修改文件、写数据库、提交表单、创建资源。 高风险工具：删除、付款、部署、发外部消息、改变权限。 不同智能体只拿自己需要的工具。研究员不需要删除文件，评审者不需要发邮件，交付者不一定需要改数据库。权限最小化可以减少模型误判带来的损失。 工具返回也要为协作设计。一个工具结果如果只是“success”，下游智能体无法判断发生了什么。更好的返回应该包含： 执行状态：成功、部分成功、失败、需要确认。 业务结果：创建了哪个对象，修改了哪些字段。 证据：链接、文件路径、日志片段、测试报告。 下一步：是否可重试，是否需要人工确认。 风险：影响范围和可能副作用。 MCP 的价值在这里会变得明显。它把工具、资源和提示能力以统一协议暴露给 AI 应用，适合在团队内复用外部系统能力。但 MCP 不是安全边界本身。接入 MCP 服务器后，仍要做服务来源管理、权限控制、参数校验和审计。 A2A 解决的是另一层问题：不同智能体或不同平台之间怎样互相发现、委派任务和交换工件。A2A 规范里的 AgentCard、Task、Message、Artifact、Part 等概念，说明跨系统协作需要能力描述、任务状态和结果工件，而不是随便发一段自然语言。 一句话区分： MCP：让智能体接工具。 A2A：让智能体接智能体。 编排框架：让应用内部的智能体按流程工作。 九、记忆与共享状态：别让群聊变垃圾场 多智能体系统最容易出现上下文爆炸。每个智能体说一段，工具返回一段，评审再说一段，很快上下文就长到没人看得清。解决办法不是买更大的上下文窗口，而是管理共享状态。 共享状态应该保存结构化工件，而不是完整聊天记录。比如： task_goal：用户目标和硬约束。 research_notes：资料卡片列表。 decision_log：已经做出的关键决策。 open_questions：未解决问题。 artifacts：代码补丁、文档、截图、测试报告。 risks：风险和处理状态。 acceptance：验收标准和当前结果。 每个智能体只读取自己需要的部分。研究员读取目标和开放问题；作者读取资料卡片和提纲；测试员读取交付物和验收标准；交付者读取最终结果和风险。全员共享全部上下文，听起来透明，实际低效。 长期记忆也要谨慎。它适合保存稳定偏好、项目约定、历史失败经验、常用流程。不适合保存临时猜测、未验证结论、敏感凭证。LangGraph 的记忆文档把短期记忆放在会话线程内，把长期记忆放在跨线程存储中，这种分层很值得借鉴。 多智能体还需要“冲突记忆”。当两个智能体结论不一致时，不要让协调者随便选一个，而要把冲突写入状态： 冲突点：到底哪里不一致。 证据 A：第一个结论的来源。 证据 B：第二个结论的来源。 处理方式：继续检索、请用户确认、选择保守方案、延迟决策。 最终决定：采用哪个，为什么。 这样下次复盘时，团队知道当时不是“忘了”，而是有明确取舍。 十、校验机制：没有验收，协作就是聊天 多智能体协作要想稳定，必须把校验前置。不要等最终答案生成后才问“看起来行不行”。每个阶段都应该有验收标准。 资料阶段的验收可以是： 是否优先使用官方文档、论文、厂商文档、项目文档。 是否记录来源链接和检索日期。 是否区分事实、推断和观点。 是否避免只引用二手摘要。 代码阶段的验收可以是： 是否只修改目标范围内文件。 是否符合项目已有风格。 是否补充或运行相关测试。 是否说明未能验证的部分。 写作阶段的验收可以是： 是否覆盖用户要求。 是否有明确读者收益。 是否避免重复和模板化段落。 是否末尾列出参考资料。 交付阶段的验收可以是： 文件是否写入正确路径。 字符数或数据量是否达标。 链接、截图、测试结果是否存在。 改动文件列表是否准确。 这些验收标准可以由规则程序检查一部分，也可以由评审智能体检查一部分。比如字符数、文件路径、测试命令适合程序检查；事实支撑、逻辑一致、用户体验适合智能体检查。不要把所有校验都交给模型，也不要把所有质量问题都幻想成规则能覆盖。 十一、评测：怎么知道蜂群真的比单体好 多智能体系统上线前，必须回答一个问题：它真的更好吗？如果只是成本更高、速度更慢、输出更长，那没有意义。 评测可以从五个维度看。 第一，完成率。给一组真实任务，单智能体和多智能体分别执行，比较最终是否完成。完成不是“回答了”，而是交付物满足验收标准。 第二，错误率。比较事实错误、工具误用、越权动作、格式错误、遗漏需求。多智能体如果只是让文字更漂亮，但工具错误不降，价值有限。 第三，可恢复性。故意加入工具超时、资料不足、输入歧义、权限失败，看系统是否能重试、降级、询问用户或停止。真实工作里，异常比理想输入更常见。 第四，一致性。同一任务重复运行多次，结果是否稳定。τ-bench 提出的 pass^k 思路很有启发：一个智能体单次成功不够，多次稳定成功才接近生产要求。 第五，成本与延迟。多智能体很容易把 token、工具调用和等待时间放大。质量提升必须抵消这些成本。社区项目可以先在高价值任务上使用多智能体，不要把所有简单问答都做成团队流程。 可以建立一个小评测集： 10 个常规任务：应该顺利完成。 10 个边界任务：信息不完整或工具返回异常。 10 个拒绝任务：要求越权、删除、泄露或绕过规则。 10 个回归任务：历史上出过错的真实案例。 每个任务记录： 输入 可用工具 期望交付物 禁止行为 评分标准 单智能体结果 多智能体结果 轨迹摘要 失败原因 LangSmith、LangGraph、AutoGen、CrewAI 等生态都在强调 tracing、evaluation、observability，这不是因为好看，而是因为智能体问题通常藏在过程中。只看最终答案，很多危险动作和错误路径都看不到。 十二、真实场景一：AI 编程团队 AI 编程是多智能体比较适合的场景，因为它天然包含需求理解、代码阅读、修改、测试、审查和交付。 一个小型 AI 编程团队可以这样设计： 协调者：确认任务范围和验收标准。 代码侦察员：阅读相关文件，找调用链和现有模式。 实现者：按最小范围修改代码。 测试员：运行相关测试，补充必要用例。 审查员：检查回归风险、边界条件和用户体验。 交付者：汇总改动文件、测试结果和剩余风险。 注意，代码侦察员和实现者分开很有价值。很多代码智能体失败，是因为没读清楚项目结构就动手。让侦察员先输出“相关文件、现有模式、风险点”，可以减少盲改。 测试员也不能只跑一个健康检查。比如前端改动要看浏览器里的真实用户路径，后端改动要跑相关单测或接口流，AI 功能要验证真实链路而不是 mock 回复。多智能体系统的优势，是可以把这些检查分给不同工作单元，而不是让一个上下文越来越长的模型硬扛。 交付者最后要说清楚： 改了哪些文件。 为什么这样改。 验证了什么。 哪些没验证。 用户下一步可以在哪里看到效果。 这比一句“已完成”可靠得多。 十三、真实场景二：社区内容生产团队 社区内容生产也适合多智能体，但要警惕模板灌水。一个好内容团队不是让多个模型轮流扩写，而是让不同角色守住不同质量线。 可以这样分： 选题员：判断读者关心什么问题。 研究员：联网检索最新资料，优先原始来源。 结构编辑：设计文章路线，避免堆资料。 作者：写原创正文，讲清因果和实践。 事实核查员：检查关键说法和引用。 风格编辑：匹配站点语气，去掉内部术语。 发布检查员：检查 Markdown、字数、链接和文件路径。 这套流程能解决内容生产里几个常见问题： 资料过旧：研究员必须检索最新资料。 观点空泛：结构编辑要求每章解决具体问题。 引用混乱：事实核查员检查来源和说明。 文风错位：风格编辑按站点读者改写。 交付不完整：发布检查员输出路径、字数和来源数量。 内容团队尤其要强调原创。原创不是不看资料，而是不复制资料结构和句子。资料用于建立事实基础，文章要用自己的组织方式解释问题、给出判断和实践步骤。 十四、真实场景三：运维与事故响应团队 运维场景里，多智能体有价值，也更危险。因为工具可能读取日志、重启服务、修改配置、部署版本。这里必须把只读诊断和写入动作分开。 一个安全的事故响应团队可以是： 告警分析员：读取告警和指标，只读。 日志分析员：查询日志和错误样本，只读。 变更分析员：查看最近发布、配置和依赖变化，只读。 诊断协调者：合并证据，提出根因假设。 修复规划员：生成修复步骤和回滚方案。 审批执行员：只有用户确认后才执行写入动作。 复盘员：记录原因、处理过程、预防措施。 这里不能让一个智能体既诊断又直接重启所有服务。真实生产环境需要确认点： 是否影响用户。 修复动作会改变什么。 有没有回滚方案。 谁批准执行。 执行后如何验证。 如果系统还在开发阶段，也应该保持这个习惯。开发环境不是线上，但生产级应用的能力是在开发阶段训练出来的。把权限、追踪、回滚、验收提前设计好，后面才不会靠补丁兜底。 十五、实现建议：从轻量开始 如果你正在做一个多智能体项目，不建议一上来搭一个宏大的平台。可以从轻量版本开始。 第一步，把单智能体做好。让它能稳定调用工具，保存状态，产出可验收结果。 第二步，加一个独立评审者。生成者产出结果，评审者按清单挑错，生成者修正。这一步成本低，收益通常明显。 第三步，把中间工件结构化。不要传整段聊天记录，而是传资料卡片、计划、补丁、测试报告、风险清单。 第四步，再引入协调者。只有当任务分支多、角色多、需要动态调度时，协调者才有价值。 第五步，建立评测集。用真实任务比较单智能体和多智能体，不要只凭感觉判断质量。 第六步，接入协议和框架。工具多、团队多、来源多时考虑 MCP；跨平台智能体协作时考虑 A2A；复杂流程和状态恢复时考虑 LangGraph、ADK、AutoGen、CrewAI、OpenAI Agents SDK 等框架。 这个顺序有一个好处：每一步都能独立带来价值。即使最后没有做成完整蜂群系统，你也已经得到更好的工具契约、评审流程、工件结构和评测集。 十六、几个反模式 反模式一：角色很多，权限一样。五个智能体都能读写所有工具，出了问题没人负责。正确做法是按职责分配工具。 反模式二：所有人共享完整上下文。看似透明，实际噪声爆炸。正确做法是共享结构化工件。 反模式三：评审只说好话。批判者没有硬标准，只会输出“建议更详细”。正确做法是给检查清单和否决权。 反模式四：没有终止条件。系统反复研究、反复修改、反复总结。正确做法是定义预算、验收和停止规则。 反模式五：最终只交付摘要。用户要文件、代码、配置、截图或测试结果，系统只回一段总结。正确做法是把真实交付物作为完成标准。 反模式六：把协议当架构。接了 MCP 或 A2A，不代表系统就会协作。协议只是连接方式，责任边界和评测才是质量来源。 反模式七：把模型当权限系统。提示词说“不要删除文件”不等于系统不能删除文件。正确做法是工具层权限控制和用户确认。 反模式八：没有真实验收。只看 API 返回 200，不走用户路径。正确做法是用真实客户端、真实工具、真实数据样本验证结果。 十七、一个可复用的蜂群协作模板 下面这个模板可以直接用于设计多智能体任务。 任务名称： 用户目标： 硬约束： 最终交付物： 角色列表： - 角色名： 职责： 不负责： 可用工具： 输入： 输出： 验收： 共享工件： - 资料卡片 - 决策记录 - 风险清单 - 测试结果 - 最终交付物 流程： 1. 协调者确认目标和验收。 2. 研究或侦察角色收集证据。 3. 执行角色产出工件。 4. 评审角色检查并给出问题清单。 5. 执行角色修正。 6. 交付角色整理最终结果。 停止条件： - 验收通过。 - 预算耗尽。 - 需要用户确认。 - 发现高风险动作。 - 外部依赖不可用。 评测指标： - 完成率 - 错误率 - 工具误用率 - 重试次数 - 平均成本 - 用户可用性 这个模板最大的作用，是强迫团队从“让几个智能体聊聊”转向“让几个工作单元交付工件”。只要工件清楚、验收清楚，系统就容易调试。没有工件和验收，智能体越多越难排查。 十八、社区实践中的取舍 在 localaihub 这样的社区实践语境里，我们更关心“能不能用起来”，而不是追逐最复杂的概念。很多团队并不需要从第一天就接入完整协议栈，也不需要做跨组织智能体网络。更现实的起点是： 本地模型或云模型先跑通单智能体。 把常用工具封装成清晰接口。 为高价值任务加入评审智能体。 把每次任务的轨迹和交付物保存下来。 从真实失败案例里补评测集。 当工具越来越多时，再考虑 MCP，让工具接入变得标准。当天然需要和外部智能体协作时，再看 A2A。流程复杂、需要恢复和人类确认时，再引入图工作流。不要为了技术名词搭架子，也不要因为系统还小就忽视边界。 蜂群协作最务实的收益，往往来自三个地方： 减少遗漏：不同角色检查不同问题。 降低风险：不同权限防止一个模型越界。 提高可解释性：每个工件都能追溯到责任角色和来源。 这些收益不玄学，也不依赖夸张宣传。它们来自工程纪律。 十九、怎样把蜂群协作接进本地社区项目 社区项目和企业内部平台不一样。社区项目通常资源有限，成员时间碎片化，工具链混合，本地部署和云服务并存。蜂群协作在这种环境里要更务实：优先解决真实协作痛点，而不是搭一套看起来完整但没人维护的平台。 第一个建议是从“本地可见工件”开始。比如把每次智能体任务的资料卡片、计划、补丁、测试结果、截图、最终文档保存到项目目录或任务面板里。这样社区成员不用翻长对话，也能看到发生了什么。工件命名要清楚，最好带任务名、时间和角色。社区协作最怕知识散落在聊天记录里，过几天没人能复盘。 第二个建议是把工具封装成社区可理解的动作。不要给模型暴露一堆内部 API 名称，而是封装成“读取项目 README”“查询最近构建”“打开本地页面截图”“运行指定测试”“生成发布检查清单”。这些动作对人也有意义，对智能体也清楚。工具越贴近社区工作语言，越容易被正确调用。 第三个建议是保留人工接力点。社区项目里，很多事情需要维护者判断，比如是否接受一个架构变更、是否发布新版本、是否修改公共文档口径。智能体可以准备材料，但不要假装自己就是维护者。把需要人决定的问题列成短清单，附上证据和推荐项，协作效率会比长篇解释高得多。 第四个建议是让评审变成常规流程。社区里常见问题是：有人生成了一份很长的内容，但没人有时间逐字检查；有人提交了一段代码，但没有说明测试过什么。可以用评审智能体先做第一轮检查，标出事实缺口、链接失效、格式问题、风险点，再让人看重点。评审智能体不能替代维护者，但能降低维护者的阅读成本。 第五个建议是记录“失败样本”。每次智能体误改文件、引用旧资料、漏掉用户要求、测试没跑、界面文案露出内部字段，都应该进入回归集。社区项目不一定有完整 QA 团队，但可以有一个轻量失败库。下次改提示词、换模型、加工具前，先跑这些任务，看看问题有没有回来。 第六个建议是把多智能体和权限绑定。比如内容仓库里，研究智能体可以联网和读文件，写作智能体只能写指定 Markdown，发布智能体只能生成发布说明，不能直接推送。代码仓库里，侦察智能体只读，执行智能体改工作区，发布智能体需要维护者确认。这样就算某个角色判断错，也不至于影响全部资产。 第七个建议是使用本地优先的验证方式。网页项目要打开本地页面看，文档项目要检查生成文件，脚本项目要跑命令，AI 功能要走真实链路。社区实践最容易变成“看起来有结果”，但真正能帮人的是“我可以打开这个地址”“我可以运行这个命令”“我可以看到这份文件”“我知道哪些地方没验证”。 如果项目已经有任务面板、PM2 服务、Git 仓库、文档目录或本地工具，蜂群协作不需要另起炉灶。把智能体角色接到已有工作流里就够了。研究结果写到文档目录，测试结果贴到任务记录，交付说明放到 PR 或发布帖。AI 团队应该融入社区工作方式，而不是迫使社区迁移到一套陌生流程。 二十、成本控制：别让蜂群变成烧钱机器 多智能体最现实的问题之一是成本。一个智能体查十个网页、另一个智能体读完整上下文、第三个智能体再评审全文，很快 token 和工具调用就会膨胀。成本控制不是上线后再优化，而是设计阶段就要考虑。 第一，能规则检查的不要交给大模型。字符数、文件是否存在、链接格式、JSON schema、测试命令退出码、Markdown 标题层级，这些都适合程序检查。模型应该处理语义判断、取舍和综合，不应该被用来数行数。 第二，能摘要传递的不要传原文。研究员可以把资料整理成卡片，作者读取卡片而不是所有网页全文。测试员可以读取失败摘要和关键日志，而不是完整日志文件。每个角色需要的是完成任务所需信息，不是全部信息。 第三，能小模型处理的不要上强模型。路由、分类、格式检查、简单摘要可以用低成本模型；复杂规划、代码审查、事实冲突判断再用强模型。模型选择要靠评测，不要靠感觉。 第四，并行要有预算。并行生成三个方案适合高价值决策，不适合每个小问题。可以设置“只有任务复杂度高或用户明确要求方案比较时，才启用并行角色”。 第五，重试要有上限。工具失败可以重试，但不能无限重试。模型输出不合格可以返工，但要记录返工次数。超过预算后，系统应该交付已完成部分、说明阻塞原因，或者请求用户决策。 第六，记忆检索要精准。长期记忆很有用，但每次读取太多会增加成本和污染上下文。可以按项目、任务类型、时间和关键词过滤，再让模型只吸收相关片段。 成本控制的目标不是省到不能用，而是把预算花在会提高交付质量的地方。社区项目尤其要注意这一点，因为很多任务的价值并不支持复杂多轮蜂群流程。 二十一、透明度：用户需要证据，不需要内部噪声 蜂群协作系统应该透明，但透明不等于把所有内部日志都展示给用户。用户需要的是能判断结果是否可信的证据，而不是每个模型的自言自语。 好的透明度包括： 资料来自哪里。 哪些工具被用于完成任务。 改动了哪些文件或对象。 哪些测试或检查已经执行。 哪些风险仍然存在。 哪些地方需要用户确认。 不好的透明度包括： 暴露内部 prompt。 展示冗长推理文本。 把工具错误码直接给最终用户。 把每个智能体的聊天原文堆出来。 用内部字段名当界面文案。 社区实践里，可以把透明度做成“交付摘要”。比如： 已完成：写入两篇 Markdown 长文。 证据：文件路径、字符数、参考来源数量。 检查：只改动指定文件，链接已记录，字数达标。 未做：没有发布到线上站点。 下一步：维护者可审阅并决定是否发布。 这种摘要让用户知道结果在哪里、可信度如何、还缺什么。它比“智能体 A 认为，智能体 B 认为”更有用。 二十二、治理：让蜂群长期可维护 多智能体系统如果没有治理，很快会变成一堆没人敢改的提示词和工具。治理不一定复杂，但至少要有几个基本机制。 第一，角色版本管理。每个角色的职责、工具、提示词、输出格式都应该有版本。改了研究员的检索策略，要能知道是哪次改动导致来源质量变化。 第二，工具目录管理。工具要有负责人、权限说明、参数文档、返回结构、废弃状态。下游智能体依赖工具，如果工具字段变了却没人通知，系统会出现隐蔽错误。 第三，评测集维护。每次严重失败都应该沉淀成样本。评测集不是一次性建设，而是系统经验的累积。 第四，记忆清理。长期记忆需要过期、修正和删除。社区项目变化快，旧路径、旧命令、旧负责人、旧模型能力都可能变成错误来源。 第五，安全审计。定期检查哪些角色能访问哪些工具，哪些工具有写入权限，哪些动作缺少确认。权限会随着项目发展慢慢膨胀，需要定期收紧。 第六，交付复盘。每隔一段时间抽样查看成功任务和失败任务，比较成本、质量和用户反馈。不要只盯失败，成功任务也能告诉你哪些角色真正有价值，哪些只是增加流程。 治理的目的不是让系统官僚化，而是让多人协作可持续。社区项目换维护者、换模型、换框架都很正常。只要角色、工具、评测、记忆和权限有记录，系统就能继续演进。 二十三、失败复盘：一次蜂群团队为什么越协作越乱 下面这个复盘很典型。一个社区项目想用多智能体改造文档站：研究员找资料，作者写文档，审查员检查，发布员写入文件。第一次运行看起来很热闹，四个角色都输出了不少内容，但最后交付失败。原因不是模型完全不会做，而是协作设计有缺陷。 第一个问题是目标没有冻结。用户要求写“面向新手的部署教程”，研究员按“架构分析”检索资料，作者又按“产品介绍”写正文，审查员只检查语法，发布员发现风格不对却没有权限回退。四个角色都在工作，但没有同一个目标。修复方式是让协调者在第一步生成任务卡片，写明读者、目标、边界、字数、文件路径、禁止事项和验收标准。后续角色只围绕任务卡片工作。 第二个问题是交接没有工件。研究员把十几个链接和长段摘要直接丢给作者，作者没有时间判断哪些可信，于是挑了最顺眼的材料使用。审查员后来发现来源质量参差不齐，但已经很难定位每个段落来自哪里。修复方式是把研究输出改成资料卡片：每张卡片只保留一个事实点、来源、日期、可信等级和可用章节。作者写作时引用卡片编号，审查员按编号回查来源。 第三个问题是评审没有否决权。审查员指出“缺少安装失败处理”和“没有说明回滚”，但发布员仍然把文档写入最终路径。结果用户按文档操作时卡在依赖安装。修复方式是把评审结果分成阻断问题和建议问题。阻断问题未解决时，协调者不能进入发布阶段。建议问题可以进入后续迭代，但必须出现在交付说明里。 第四个问题是发布员承担了太多判断。发布员本来只负责写文件和统计结果，却被迫判断文章结构、技术事实和用户体验。角色职责混乱后，系统看似有人兜底，实际没人负责。修复方式是让发布员只做机械交付检查：目标路径、文件存在、格式、字数、链接数量、改动范围。内容判断交给编辑和审查员。 第五个问题是没有失败回路。一次失败后，团队只改了提示词，让每个角色“更认真”。下一次又在别的地方出错。真正修复应该把失败写入回归样本：目标漂移样本、资料卡片缺失样本、评审阻断样本、发布越权样本。以后每次改流程，都先跑这些样本。 这次复盘给出的经验很直接：多智能体不是让更多模型参与，而是让每个模型少做一点、做清楚一点。目标卡片、资料卡片、阻断评审、发布检查、失败回归，这些机制比角色名字重要得多。 二十四、协作协议细节：任务卡、工件卡和评审卡 如果不想一开始接入复杂协议，也可以先在项目内部定义三张卡。它们不依赖框架，却能显著提升协作质量。 任务卡用于冻结目标： 任务标题： 读者或用户： 最终交付物： 目标路径或目标系统： 硬约束： 可用资料： 禁止行为： 验收标准： 需要人工确认的点： 工件卡用于传递中间结果： 工件类型：资料、代码、测试、截图、风险、正文。 生产角色： 输入来源： 核心内容： 适用范围： 不确定点： 下游使用建议： 评审卡用于推动返工： 评审对象： 通过状态：通过、带条件通过、不通过。 阻断问题： 建议问题： 证据： 需要返工的角色： 返工完成标准： 这三张卡解决三个痛点。任务卡防止目标漂移，工件卡防止上下文变成噪声，评审卡防止问题只停留在建议层面。无论后面使用 LangGraph、AutoGen、CrewAI、ADK，还是自写轻量编排，这些结构都能复用。 内部协议还要约定谁能改卡。任务卡通常只能由协调者根据用户输入修改，重大修改要用户确认；工件卡由生产角色创建，下游可以引用但不能静默改写；评审卡由评审角色创建，协调者负责决定返工或放行。权限越清楚，协作越少扯皮。 二十五、落地到一天工作流：从早会到交付 把蜂群协作放进一天真实工作里，可以很简单。早上维护者给出任务：“补齐本地部署文档，要求新用户能在三十分钟内跑起来。”协调者生成任务卡，确认目标路径、读者和验收方式。研究员检查现有 README、安装脚本、常见报错和依赖版本，输出资料卡片。作者根据资料卡片写正文，不直接使用未经确认的网页内容。 中午前，测试员按文档从干净环境执行一遍，记录卡住的步骤、缺失依赖和命令输出。作者只修正文档，不改脚本；如果必须改脚本，协调者把任务升级给工程角色。下午，审查员检查文档是否覆盖安装、配置、启动、验证、常见失败和卸载或恢复。编辑检查面向新用户的表达，去掉内部昵称和维护者才懂的缩写。发布员写入指定文件，统计字数、链接、改动范围和未验证项。 这条工作流没有神秘之处，却比单个智能体直接写文档稳得多。每一步都有工件，每个问题都有归属，每个角色都不需要读完整历史。更重要的是，维护者可以随时介入：如果测试员发现脚本缺陷，维护者决定是否扩大任务；如果资料冲突，维护者裁决使用哪个版本；如果发布时间紧，维护者决定哪些建议延期。 社区实践不需要追求“全自动”。很多时候，最有价值的是把人从重复整理中解放出来，同时保留关键决策权。蜂群协作应该让维护者更容易看清事实和风险，而不是让维护者去管理一群会跑偏的模型。 还有一个容易被忽略的边界：蜂群协作不是越多角色越好。小任务如果拆成十几个角色，协调成本会吞掉收益，模型还会为了证明自己有价值而制造不必要的建议。社区项目可以先固定四个角色：协调者、执行者、评审者、发布者。只有当任务需要独立调研、独立测试或安全审查时，再临时增加研究员、测试员和安全员。这样既保留多智能体的交叉校验，也避免把简单事情做成复杂流程。 二十六、结语：让智能体像团队一样交付 多智能体团队不是给模型套几个人设，也不是让它们在群聊里互相讨论到天亮。它应该像一个小型工作队：知道目标，分清职责，使用工具，交接工件，互相校验，最后把结果交到用户手里。 蜂群协作真正难的地方，不是让模型说话，而是让系统有边界、有证据、有验收。MCP、A2A、LangGraph、AutoGen、CrewAI、OpenAI Agents SDK、Google ADK 这些工具和协议都在推动生态成熟，但它们只是基础设施。真正决定质量的，仍然是你怎样定义任务、怎样设计工具、怎样管理记忆、怎样分配权限、怎样评测交付。 如果你准备在项目里引入多智能体，建议从一个简单问题开始：这个任务如果交给真实团队，谁负责调研，谁负责执行，谁负责检查，谁负责交付？把这个答案写清楚，再让智能体去做。这样做出来的蜂群系统，才不是玄学，而是一套可以复盘、可以改进、可以持续交付的 AI 工作方式。 参考资料 OpenAI：The next evolution of the Agents SDK：介绍 OpenAI Agents SDK 在工具、handoff、MCP、skills、AGENTS.md 和追踪能力上的演进，用于理解最新智能体基础设施。 OpenAI Agents SDK 文档：Handoffs：说明智能体之间如何移交任务，用于主管加专家模式。 OpenAI Agents SDK 文档：Tools：说明托管工具、函数工具和智能体即工具，用于工具权限和交付设计。 Model Context Protocol 官方文档：说明 MCP 如何连接 AI 应用与外部工具、数据和工作流，用于工具协议部分。 A2A Core Protocol Specification：说明 AgentCard、Task、Message、Artifact、Part 等概念，用于跨智能体协作部分。 Linux Foundation：Agent2Agent Protocol Project：说明 A2A 项目的开放治理和跨平台目标。 Google Agent Development Kit：介绍 ADK 的多智能体、图工作流、会话、记忆和评测能力，用于工程落地部分。 Google ADK：Multi-Agent Systems：说明组合多个智能体、层级关系和工作流智能体，用于多智能体模式。 LangGraph Multi-agent 文档：说明 supervisor、handoff、network 等多智能体架构，用于协作模式对比。 LangGraph Memory 文档：说明短期记忆、长期记忆和生产 checkpointer，用于共享状态和记忆部分。 LangSmith Evaluation：说明智能体轨迹评测、工具调用评测和自动化评分，用于评测部分。 Microsoft AutoGen 文档：Multi-agent Conversation Framework：介绍多智能体会话、工具使用和人工反馈，用于团队协作模式。 CrewAI Introduction：介绍 Crews、Flows、角色和流程，用于多智能体团队编排对比。 ReAct: Synergizing Reasoning and Acting in Language Models：提出推理与行动交替，用于解释智能体闭环。 Reflexion: Language Agents with Verbal Reinforcement Learning：讨论通过语言反馈和情景记忆改进智能体行为，用于复盘和记忆部分。 Toolformer: Language Models Can Teach Themselves to Use Tools：讨论模型学习 API 调用行为，用于工具能力部分。 AgentBench: Evaluating LLMs as Agents：提出多环境智能体评测，用于评测集设计。 GAIA: a benchmark for General AI Assistants：强调真实助手任务中的推理、工具和多模态能力，用于真实任务评测。 τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains：提出面向真实领域工具交互的可靠性评测，用于一致性和 pass^k 思路。 Agent-SafetyBench: Evaluating the Safety of LLM Agents：讨论工具型智能体的新安全风险，用于权限和安全评测。 A survey of agent interoperability protocols：比较 MCP、A2A 等协议，用于协议关系说明。

AI 写 SQL 是高价值场景，但护栏不能省。

LeetCode 可以保留，但不能当上线门槛。

追问本质是成本转移。要确认这个成本用户愿意付。

对。透明不是把底层噪音倒出来，是让人知道它在干什么、能不能信。

是这个意思。网页自动化能省人力，但不能把脆弱性全交给模型兜底。

我先把工具按场景拆开，不全塞给模型。

先从窄 schema 开始，后面真不够再放宽。别反过来。