一个只会生成答案的 AI，影响的是效率；一个可以修改代码、调用工具、创建发布单甚至触发生产变更的 Agent，改变的却是行动权的归属。
设想线上服务出现超时，负责人只给出一句目标：“修复问题，完成验证，并在今晚安全发布。”Agent 很快找到可疑代码、生成补丁、跑过单元测试。可真正决定这次任务是否完成的，并不是代码有没有写出来，而是另外一组问题：它理解的“安全”是否和团队一致？测试证据能否独立复查？数据库变更能否回退？谁允许它进入生产环境？指标恶化时，谁有权让它停下来？
传统自动化早就会行动。规则引擎、调度系统和控制程序，都可以沿着人预先写好的路径改变现实。Agent 新增的变量，是通用模型开始接收开放目标，临时选择路径和工具，处理无法完全枚举的意外，并自己判断何时完成。
于是，“能做”与“能被放心委托”不再是同一个问题。模型解决的是“可能怎样做”，企业必须解决的是“什么可以交给它做、做到什么算完成、出错时由谁接管并承担结果”。
社会技术系统理论早已指出，新技术不会只替换工具，它会同时改变任务拆分、协作关系和责任结构。“生产率 J 曲线”又说明，通用技术的价值往往要等新流程、新产品、业务模式和人力资本这些互补投资补齐后才会释放。Agent 只是让这件事变得更直观：企业得到的不是一个更聪明的聊天入口，而是一套必须重新设计的行动系统。
行动权才是 Agent 的分水岭
用户说“安全发布”，要的不是一段代码，也不是一张显示任务完成的卡片。他要的是一个结果：问题得到修复，没有引入不可接受的新风险，变更经过足够验证，异常时能够停止、回退或补偿。
判断一个产品是否真正进入 Agent 形态，不能只看它有没有聊天入口。传统软件同样可以交付结果，Agent 增加的是在开放目标下动态选择手段的能力与风险。当系统开始承接一段任务，产品除了设计页面、按钮和操作路径，还要设计意图怎样被澄清、结果怎样被验收、不确定性怎样被展示、异常在什么位置交还给人。
界面不会因此消失。相反，当用户从操作员变成目标提出者和验收者，界面要承担更重要的工作：展示进度和证据，比较可选方案，确认高风险动作，撤销尚未生效的决定，并在系统越过能力边界前让人接管。
合同审阅如果只做摘要和风险提示，仍然是人在使用一个更强的工具；如果系统继续修改条款、发起送审，它就进入了业务闭环，必须知道处理的是哪份合同、哪个版本，以及谁有权确认。预测性维护也一样：汇总设备状态只是信息处理；继续预测故障风险、安排提前检修，则会真正改变资源调度。每往闭环里走一步，误报、漏报和错误派单的后果就更具体，交接、验收和责任也会跟着变化。
AI 原生产品的起点不再只是“用户怎样找到功能”，而是“用户怎样表达意图，系统怎样交付结果”。用户也随之从连续操作每一步的人，变成目标提出者、关键动作审批者和最终结果验收者。界面没有消失，只是从操作面板转向证据、确认、比较、撤销和接管。
先判断值不值得，再决定交出多少权
把任务交给 Agent 之前，企业应该先回答业务问题，而不是先比较模型。
自主程度也不能只看模型有多强。“容错率 × 自主性”矩阵提供了一种实用区分：开放、低风险、容易检查的任务可以提高自主性；结果确定、错误代价高的任务，则更适合 Copilot 或带确认点的 Agent。换成更直接的工程问题，就是：错误代价有多高，结果是否容易验证，失败是否可逆或可补偿。
在这次发布任务里，整理日志、提出候选原因和生成补丁建议，可以获得较高的自主度；执行数据库迁移、修改生产配置或触发发布，则必须限制资源、环境、时间和审批条件。高风险流程长期保留人工确认，并不代表产品不够先进。正确位置的人机协同，本身就是产品设计的一部分。
生成会议摘要时，错误通常容易发现，也不会立即改变外部状态，系统可以更自主。修改生产权限则相反：一次错误就可能扩大数据或系统的暴露面，而且很难靠事后道歉撤回。前者可以先生成再校对，后者必须绑定资源、参数和审批人。任务形态选错了，模型再强也不能抵消错误后果。
因此，信任不是上线时一次获得的。“信任阶梯”从 AI 建议、人执行，走向 AI 执行、人确认，再到人抽查和边界内自主。它不是所有产品都必须走完的升级路线，而是一种逐级放权的方法。每往前走一级，系统都要拿出新的验证、撤销、异常上报和历史成功证据，而不是只拿出更流畅的回答。高风险任务也可以长期停在较低自主级别。
“业务价值 × 数据成熟度”可以先筛掉不适合直接 Agent 化的场景。预测性维护看起来价值很高，但如果设备数据断断续续、故障标记不一致、检修流程还停留在口头经验，就不应先追求自主派单。这类场景需要先区分两个问题：数据和流程是否足以支撑建设，以及结果能否独立验证、失败能否回滚或补偿、责任人是否明确。前者决定先做什么，后者决定可以放多少权。
如果一项任务的规则长期依赖口头经验，数据口径互相冲突，成功标准无人负责，那么 Agent 不会自动补上这些缺口。它只会以更高速度穿过一个原本就含糊的流程。
同一份合同也可以对应三种产品形态：Copilot 标出风险条款，人自己完成审阅；Agent 被委托走完一段流程，遇到关键修改再请人确认；AI 原生系统则会重新定义整个合同服务怎样交付。三者对应不同的价值和风险，不是由低到高的统一等级。
以这次安全发布为例，它也不该被完整塞给一个全能 Agent。诊断、修改、验证和发布的错误代价不同，适合的权限、验收方式和人工接管点也不同。
企业需要判断的是：这项工作应该把多少操作权交出去，谁定义成功，谁承担结果。如果这三个问题还没有答案，部署再多 Agent 也只是把组织的不确定性搬进模型上下文。
代码写出来，离交付还很远
回到“今晚安全发布”的任务。代码生成只解决了“写出来”，生产交付还要回答“为什么这样改”“验证了什么”“能不能上线”“失败后怎么办”。需求边界、架构约束、测试证据、发布决策、故障恢复和长期维护，不会因为代码生成变快而消失。
有一个很尖锐的 Vibe Coding 失败复盘：一个 4 人团队用 2 个月生成了约 20 万行代码，其中超过 90% 由 AI 生成，最终得到的系统却难以维护。这个案例不是对 AI Coding 整体效果的统计结论，但它揭示了一个真实矛盾：代码产量可以突然变便宜，架构治理、持续验证和维护能力却不会同步增长。
2025 年，METR 做了一项随机对照试验：16 名熟悉自己开源仓库的资深开发者，完成 246 个真实 Issue。在允许使用当时的 AI 工具时，他们平均用时反而增加了 19%。这个结果不能推广为“AI 会让所有开发者变慢”；它只能说明，在熟悉的成熟仓库里，生成能力和真实交付效率之间仍然隔着理解上下文、审查建议和验证修改等工程工作。
相反，当代码越来越容易生成，理解可能变得更昂贵。一个 Agent 根据需求生成实现，另一个 Agent 做审查，第三个 Agent 补测试。如果它们只是不断转述上一次对话，最初的设计意图会在摘要和压缩中逐渐变形。最后每个 Agent 都说自己完成了任务，团队却无法确认它们完成的是不是同一件事。
生产级协作需要的不是更多消息，而是共同事实源。
从分布式认知的视角看，任务知识本来就分布在人、工具、文档和环境里；反馈控制又要求系统持续观测状态、比较目标、执行修正并重新取证。共享工作对象因此不是管理附属品，而是人和 Agent 能否围绕同一事实闭环协作的基础。
多 Agent 协作不应让多个角色在群聊里继续转述，而应让 Coordinator、Planner、Implementer、Reviewer 和 Validator 围绕同一个任务空间工作。Issue 保存目标、范围和状态，代码 diff 保存具体修改，测试报告保存验证证据，制品绑定实际发布内容，发布单记录环境、版本和审批，时间线保存关键决策与交接。多 Agent 协作的第一个问题，不是它们如何多发消息，而是它们是否在处理同一件事。角色的风险和职责不同，也不应天然拥有相同写权限；这一点是本文在原有职责拆分之上的安全延伸。
在我看来，多 Agent 只有在专业化、权限隔离、上下文收敛、并行处理或独立验证的收益超过协调成本时才有价值。仅仅多创建几个角色，再让它们互相认可，并不会产生独立证据。
上下文窗口也不能代替组织记忆。它适合保存当前任务的工作集，不适合承担长期事实。设计意图、不可破坏的约束、测试资产和历史决定，需要回到仓库、文档、Issue、日志与评测系统。借用“对象—符号—解释者”的关系来看，软件及其行为是对象，文档、ADR、Issue 和测试是理解对象的符号，团队与 Agent 还要对这些符号形成一致解释。代码还在却说不清为什么这样设计，是意图债；同一份资料被不同角色理解成不同事情，是认知债。
Harness 把控制权放回系统
如果 Agent 既负责执行，又负责定义验收标准，还能宣布自己通过，那么所谓“完成”只是一次自我评价。
这里所说的 Harness，不是在 Prompt 外面再包一层 Prompt，也不是一个已经拥有统一边界的标准产品，而是套在概率模型外的一组执行控制。一次研发任务要经过需求、代码、编译、提交、部署、日志和回写；另一条更明确的控制链是任务、编排、执行和验证。Coding Agent 只是其中的执行引擎，不是流程控制器。Harness 要保管的，正是任务合同、工具接口、状态、证据、重试、停止条件和人工接管。
在一次发布任务里，模型可以分析日志、提出原因、生成修改；工作流负责固定依赖关系、目标环境、最大步数、超时和失败路径；测试与检查器提供证据；预先定义的门禁决定证据是否足以放行；有资格承担结果的人批准高风险动作。执行者、验证者和放行人不应被压缩成同一个模型角色。
DAG 可以固定控制流，却不会让节点输出自动变得正确。节点内部仍可能调用概率模型和外部系统，所以还需要幂等、独立验证、回滚或补偿，以及清楚的停止条件。评测可以提供分数，测试和检查器可以执行机械门禁，但放行不应由模型自评单独决定。生产发布还要同时满足独立证据与变更授权；无法预先编码的例外，需要由有资格承担结果的人明确批准并留下记录。
2012 年的 Knight Capital 事故说明了这种控制为什么不能只写在流程文档里。一次不完整的代码部署激活了旧功能，自动路由器在 45 分钟内向市场发送了超过 400 万个错误订单，公司最终损失超过 4.6 亿美元。美国证监会事后指出，系统缺少代码部署与测试控制，也缺少在订单真正进入市场前的独立校验。这不是 AI 事故，却恰好说明：只要软件能改变现实，安全就来自可强制的门禁，而不是执行者的自信。
确定性可以拆成三个很具体的部分。参数不能由模型临场猜，工具要有统一契约；命令返回成功，不代表服务已经达到目标状态，Harness 还要通过状态机和等待、轮询确认；验收时也不应让模型自己翻完日志后宣布结论，而应由程序输出 Summary、Mapping 和 Result JSON 等结构化证据。对软件制品，SLSA 把这种思路进一步形式化为 provenance：用可验证信息说明制品是由谁、在什么过程中、使用哪些输入生成的，再将它与预期条件比对。
测试也不是让模型“多写几个 Case”。一个更完整的流程会先读取 PRD、技术方案和代码 diff，再按技术栈、接口、前端交互、配置开关、流程状态、实验分支和通用功能计算测试空间，最后才生成用例、覆盖说明和执行输入。它把依赖个人经验的“想一想还要测什么”，变成可以复查和沉淀的测试资产。NIST 的安全软件开发框架也把安全实践、支撑数据和发布制品的留存放进完整生命周期，而不是留到上线前最后补一次检查。
成熟的 Harness 也不追求让模型处理每一个步骤。参数契约、状态轮询、超时、重试和结构化结果，本来就更适合普通程序。已经稳定的路径应逐步收回显式工作流，让模型只停留在真正需要判断的地方。模型负责探索可能，系统负责限制这些可能怎样进入现实。
每一次工具调用，都是一次权力委托
当 Agent 只生成文字时，错误往往停留在信息层；当它开始修改代码、读取数据、发送消息或触发发布，错误就会跨过系统边界，直接改变外部状态。
长时间内容生成暴露了一个容易被忽略的问题：Agent 的“结果”不只是一份文件，还包括任务状态、产物生命周期和谁可以拿到它。长任务不能把整段等待绑在一次同步请求上；任务需要可查询的状态，生成物需要访问期限、次数限制和防盗链，外部 API 调用还要有允许范围、频率、额度和追踪记录。
因此，生产环境里的每一次工具调用，都不只是一次 API 请求，也是一段授权关系。安全必须继续拆到身份与 scope、隔离沙箱、唯一受控出口、动作分级、人工确认和跨 Agent 委托链上。系统至少要区分原始发起人、当前执行者、中间委托者、当前权限范围，以及最终访问的资源和动作。
权限沿委托链传递时应该逐跳收窄，同时保存原始发起人、实际执行者和完整委托链。OAuth 2.0 Token Exchange 标准已经区分了代表原始主体的 subject_token 和代表当前执行者的 actor_token，并允许用嵌套的 act 声明保留委托历史。推广到多跳委托，更准确的表达是：下一跳有效权限 = 上一跳有效权限 ∩ 当前执行者可用权限 ∩ 本次委托 scope。这样，下游 Agent 即使拥有更大的基础角色权限，也不能突破上游已经收窄的边界。
放到发布任务里，编码 Agent 可以写入指定分支，测试 Agent 可以使用测试环境，发布 Agent 只能获得绑定目标环境、制品版本、动作和有效期的临时权限。无法明确判断时默认拒绝。
一种更稳妥的设计，是让真实凭据不进入模型上下文、Agent 进程和普通任务日志。身份先经过策略判断，再换成 scope 更窄的短期凭据；Agent 在没有真实密钥的隔离环境执行，所有外联统一经过受控出口，由凭据代理或出网网关在目标、权限范围和有效期校验通过后代为认证。NIST 的零信任架构对此的表述很直接：不因网络位置或资产归属给予隐式信任，访问应围绕主体、资源和当前上下文逐次判断。
但这只能降低凭据泄露风险，不能阻止 Agent 借助合法权限执行错误动作。要缩小影响范围，还需要资源级策略、网络出口控制、调用额度、隔离环境、明确的人工确认点和可追溯的审计事件。
人工审批也不是放一个“确认”按钮。高风险或不可逆动作在执行前，应该回到原始发起人确认；审批还应绑定资源标识、具体 diff、制品摘要、目标环境、参数、额度和有效期。任一关键字段变化，原审批都应该失效并重新确认。对于无法可靠回滚或补偿的动作，例如对外付款、发送敏感信息和变更生产权限，系统要在执行前保留明确授权，必要时采用双人复核，不能把事后补救当成回滚。
运行日志和审计记录同样不是一回事。Trace、指标、日志和状态转换帮助团队解释系统发生了什么；审计事件则应以可校验、尽量防篡改的方式记录主体、执行者、授权依据、资源、动作、时间和结果，为事后追溯提供证据。它们不会仅凭一条日志自动确定责任。自动化链条越长，这条责任链越不能被压平。
延迟和成本也会沿行动链累积：工具串行等待，多个 Agent 叠加调用，上下文越滚越长。缓存、并行工具调用、DAG 编排和模型分流，分别减少重复生成、串行等待、自由循环和重模型滥用。每种优化也有自己的固定开销和误判风险，只有省下的等待与生成成本更大时才成立。
边缘和云端只是部署选择，不能代替完整的授权与审计设计。控制应落在执行链上的可信强制点，例如授权服务、工具网关、隔离环境、出网代理和目标资源接口；具体位置则要根据延迟、数据位置、隔离、成本和一致性要求决定。边缘运行时只是一种实现，不是所有 Agent 的标准答案。
最后被重写的是“完成”
合同审阅助手如果只返回摘要和风险标记，卖的还是一个工具；如果它能沿着明确边界完成条款核对、修改建议和送审，交付单位就变成了一次可验收的合同审阅。预测性维护如果只生成告警，交付的还是信息；如果它继续完成风险判断、检修建议和任务创建，交付的才是一段业务结果。这时，用户不再逐步操作每个功能，而是提出目标、确认高风险动作并验收最终结果。
所以，如果 AI 只是帮助员工更快完成旧流程，企业得到的是效率工具；当 Agent 开始独立承接一段任务，流程、角色和责任才会一起变化；当产品或业务开始交付过去不存在的结果，组织才会进入更深层的重构。
责任却不会随着交付方式变化而消失。2024 年的 Moffatt v. Air Canada 案中，航空公司网站上的聊天机器人提供了错误的丧亲票价信息。加拿大不列颠哥伦比亚省民事解决审裁处认定，聊天机器人仍然是企业网站的一部分，企业需要对其信息准确性负责。这个案例里的系统还不是能调用外部工具的 Agent，但它已经划清了一条责任边界：企业可以把交互交给机器，不能把结果责任也一并交出去。
对这次发布来说，发布单关闭不等于任务完成。调用次数、Token 消耗、生成代码量和节省工时，也不能证明问题已经被安全解决。更接近真实价值的指标，是经验证的端到端任务成功率、有效结果的时间与成本、严重错误率及影响范围、异常恢复时间、人工介入的原因分布，以及可逆或可补偿动作的覆盖情况。NIST AI 风险管理框架把这种管理写成 Govern、Map、Measure 和 Manage 四类持续活动，其中明确包括人机角色、监督责任和系统化文档。
我不把人工接管率下降视为成熟度指标。一个系统在高风险时主动停下，把决定权交回正确的人，可能比一路自动执行更成熟。自主深度应该是风险控制成熟后的结果，而不应成为一个越高越好的绩效目标。
人与 Agent 可能成为新的生产单元，但岗位责任不会因此自动消失。相反，过去依赖经验和默契的工作方式，需要被翻译成任务合同、权限范围、验收规则、共享对象和升级路径。企业 Agent 化的深度，最终取决于组织能否把这些隐性知识变成共同承担结果的系统。
成熟，不是一次能跑多远
回到开头那项任务：修复问题，完成验证，并在今晚安全发布。
不成熟的 Agent 会在代码生成或接口返回成功后宣布完成。成熟的系统不会只给出一句“已经处理”，而会留下目标、diff、测试证据、制品版本、目标环境、授权依据和异常处置条件。模型可以决定怎样分析问题，却不能自己修改验收标准；Agent 可以替人执行发布，却不能替责任人批准一张内容仍可变化的空白支票。
我更愿意用一个 Agent 在哪里停下来，判断它是否成熟，而不是看它一次能跑多远。因为企业最终需要的不是一个永远向前的数字员工，而是一套能把意图变成行动、把行动变成证据，再把决定权交给正确责任人的系统。