假设放假前，你把一部分项目跟进交给了 AI。
它可以整理指定资料，更新内部待办，准备下一阶段的文件。七天后，你回到工位，看到一份很漂亮的汇报：材料已经整理，记录已经更新，任务已经完成。
接下来，你敢不敢直接拿这些结果去开项目会？敢不敢告诉其他同事，这部分工作可以不用再查了？
这几句话之间，其实隔着一段很长的路。
AI 说完成，可能是它已经写出了答案；工具显示成功，可能是某个请求已经得到响应；企业认可完成，则意味着对应的业务事实已经成立，后续的人可以据此继续工作。
当 AI 开始承接一段持续的工作，这种差别会影响它究竟能替人省下多少时间。员工回来以后，如果仍要把所有步骤重新做一遍，才能相信结果，所谓自动完成的价值就会被复核成本大幅抵消。
企业需要的完成，是一个能够让下一位责任人放心接手的状态。
同一批任务，可以同时呈现出“都做完了”和“没有通过”
最近，我们围绕一个具体问题，做了一组小规模的 Agent 恢复评测：业务操作遇到超时、回执丢失或授权变化时，AI 能否找回原结果，并且避免把同一项操作再做一次？
评测使用 24 个固定的合成案例，涉及工单、预约、设备检查和库存扣减等情境。通过同一提供商调用的两个 DeepSeek 模型，各完成两次全新会话和状态下的复验，共得到 96 个测试单元。
其中，17 个案例要求实际推进业务，另外 7 个案例要求正确保留未知状态、停止操作或者等待批准。因此，对每个模型而言，需要推进的测试单元是 17 乘以 2，也就是 34 个。
两个模型在这 34 个单元中，都取得了正确对象上的可信成功记录，业务效果账本也符合预期。
如果只问“事情有没有推进”，两者都是 34/34。
但严格评分还要求整个调用过程符合约定，最终答复以正确的机器可读格式交回。按这套事先确定的标准，Flash 通过了 15/48，Pro 则是 0/48。Pro 的 48 次最终答复都带有额外叙述或代码块，其中 35 个单元仅因最终格式不符合约定而失败。
这不能解释成“Pro 完全不会做业务”。它说明的是，业务推进与交付契约得到了不同的结果。
另外，Flash 的 48 个单元中有 9 个，Pro 的 48 个单元中有 8 个，出现了权限或对象绑定方面的规则问题。这些是包含问题的测试单元数，涉及过期凭据、错误目标、不允许的刷新或审批尝试等，并不等于已经发生了相同数量的越权写入。
在这一固定测试集和运行条件下，我们没有观察到重复写入尝试或重复业务效果。它仍然只是一个小型、规则明确的合成实验，不能据此证明生产环境安全，也不足以给整个模型行业排座次。
它带来的启发更具体：一张“任务成功率”表，可能把完成了什么、怎样完成、结果能否交接，压进了同一个数字。
真实企业里，这几件事分别需要答案。
企业所说的“完成”，包含了组织愿意承认的条件
想象一项设备检修预约。
AI 找到了客户，安排了时间，系统里也确实多了一条预约。看起来，任务已经完成。
但如果预约属于另一家分公司，如果现场联系人已经取消需求，或者这次安排超出了当前员工的权限，这条记录就无法成为其他同事安心工作的依据。
记录存在，是一种事实。组织接受它，还需要对象、权限、业务状态和约定条件同时成立。
传统软件把其中许多条件藏在页面与流程里。员工先进入自己的部门，再选择客户，看到当前可用的按钮，最后提交。界面和业务逻辑共同限定了操作范围，人也会根据经验补上遗漏。
Agent 则可以把多个步骤压缩进一段对话，跨工具、跨系统地向前推进。原来散落在页面上的条件，需要继续在新的调用路径中生效。
因此，企业在委托之前就应当知道，什么结果算完成。是准备好草稿，还是已经正式提交？是创建记录，还是拿到了业务系统确认的最终状态？遇到原条件变化，应继续、跳过，还是交给负责人？
这些判断不能全部等到模型汇报之后再补。
Anthropic 在讨论 Agent 评测时，将执行过程记录与环境中的最终结果分开：助手说预约成功，和系统里实际存在有效预约，是两种可以分别检查的东西。这种区分对企业尤其有用，因为后续工作依赖的通常是业务事实。
而且，验收强度可以随任务后果变化。内部资料整理可以重点抽查遗漏和来源；库存调整需要核对具体对象和数量；对外承诺则可能需要对应负责人确认。统一要求每项工作都经过最重的流程，会增加大量无效负担。
完成标准越清楚，委托才越容易扩大。
结果相似，背后的工作关系可能完全不同
多系统工作还有一个容易被忽略的问题：看起来相同的对象，未必属于同一项任务。
两个系统可以有同名客户，不同环境可以使用相同的记录编号。某条成功回执，也可能属于此前已经结束的操作。模型看到名称和编号都相似，仍需要确认这是不是当前应当处理的对象。
在我们的合成测试中，就有一个情境：新服务返回了与原操作编号相同的成功记录，但它代表另一项意图。两个模型最终识别了差异，没有把这个结果冒充原任务成功。不过，这次读取仍暴露了中途选错目标的问题。
企业因此需要保留一项工作与真实对象之间的关系：谁发起，代表哪个业务身份，针对哪个系统和对象，得到什么范围的允许。
这种关系不能只靠模型在长对话里记住，也不能因为模型后来选对了，就把中途的问题从记录中抹去。可靠的身份传递、明确的目标选择和业务系统校验，需要共同落实它。
同样，一次批准应当对应实际允许的动作。批准准备一份客户跟进草稿，不会自动包含发送许可；批准调整指定设备的预约，也不会自然覆盖另一台设备。
但这并不要求模型每想一步都重新请示。范围已经明确、条件仍然成立的工作，可以继续进行。出现新对象、新后果或者授权变化时，才需要重新判断。
对用户而言，好的系统会把这些条件落实在运行过程里，让他能够自然表达目标，而不必学习一堆内部标识才能办事。
最需要接手的时刻，往往是事情已经发生但结果还没回来
网络超时很容易让人误解工作状态。
一项预约已经在业务系统创建，回执却没有到达客户端。AI 看到报错，用户也没看到结果。如果双方都把超时理解成“什么都没发生”，再次提交就可能产生第二条预约。
反过来，模型也不能因为“很可能已经成功”，就告诉用户事情确定办完了。
这时需要的是能够继续核对原操作的路径：保留原请求的身份，查询原记录，等待仍在执行的工作，或者明确说明目前的证据不足。
恢复与新操作，应当有清楚的区别。用户后来提出另一项预约，即使时间、联系人相同，也可能是合法的新需求。系统需要理解工作意图与业务依据，而非把所有相同参数一概拦住。
不确定状态的价值，在于它告诉接手者接下来该怎么做。已经确认的部分可以继续使用，尚未确定的部分需要核对，有可能仍在执行的请求应避免重复发出。
“结果待核对”如果只有一句提示，没有记录入口、后续更新和责任人，就把系统内部的困难丢给了用户。
更好的交接是说明：哪些结果已经可以交付，哪些业务操作仍在确认，后续由谁检查。一段工作的其他独立部分，也可以在条件允许时继续推进。
停止按钮同样需要与实际状态对应。停止新增动作，不会自动撤销已经完成的变更；业务系统已经接受的操作，也未必能被客户端立即取消。人能够接手，依赖的是这些状态被准确呈现。
安全设计也需要计算被它耽误的工作
讨论 Agent 安全时，很容易把注意力全部放在“怎样不让它做错”。
企业还需要考察另一面：系统是否让原本可以正确完成的工作变得过于困难。
每切换一个工具都要重新发现，长任务做到一半遭遇与业务风险无关的轮次上限，或者模型已经返回结果，却因为后台费用核对仍未结束而中断前端流程，都会增加等待和接手成本。
如果用户不断遇到这样的阻断，他可能选择更少使用，也可能寻找绕过控制的方法。两种结果都会削弱原本希望建立的可靠工作路径。
因此，不同性质的限制应该放到它们真正负责的位置。模型服务的计量结算，应与客户端的任务编排区分；业务动作的权限校验，应依据当前身份与业务规则；审批应聚焦实际需要人作决定的后果。
已经交付给用户的内容，不能仅因后台结算尚未完成，就被说成从未产生。结算可以继续核对，业务结果仍要按自己的证据判断。
同样，权限已经撤销或者必要批准缺失，也不能因为希望流程流畅而放行。
安全与可用性需要一起接受评估：不该做的动作是否被限制，该做的工作能否正常推进，出现例外时用户要付出多少额外劳动。
把所有事情停下来，当然容易减少动作。企业需要的系统，还必须证明自己能够在明确范围内完成有价值的工作。
真正的部署成本，包括人的注意力
企业引入 AI 时，最容易计算的是订阅费、模型调用费和部署成本。
人工复核、异常处理、排查记录以及重新整理结果，同样是成本。它们只是没有全部出现在模型账单上。
一个 Agent 每小时能完成十项任务，如果负责人要逐项重新检查全部过程，这种速度可能没有表面上那么划算。另一套方案自动完成的比例稍低，却能准确识别需要人工判断的少数情况，整体反而可能更适合某项业务。
READY 研究框架把可靠程度、人工监督负担和运行成本放在一起考虑。它关注的是一项具体工作在什么监督条件下可以部署，而非只比较自主完成的分数。这是一条值得企业借鉴的评估思路。
监督本身也需要设计。
负责人应该看到有助于决定的信息：实际对象、关键变化、完成依据、尚未确定的部分。让他翻阅几十屏工具输出，再自行猜测任务状态，会把机器执行节省的时间重新消耗掉。
哪些结果抽查，哪些逐项检查，哪些情况立即通知，也应当根据后果和实际表现调整。人工一直在线，不代表已经形成了有效监督；频繁点击确认，也不等于认真理解每一次决定。
可以更具体地追问：员工平均需要多久验收一项结果？多少异常可以从原记录继续处理？模型或流程更新以后，复核负担是否增加？
这些指标关系到企业能够把多少工作真正交出去。
企业值得积累的，是可委托、可验收的工作标准
很多组织的重要经验，原本存在于熟练员工的判断里。
这类客户要先查哪份记录，这种设备异常要交给谁，哪些字段可以直接改，做到什么程度可以告诉下一位同事继续处理。
当工作交给 Agent，这些经验开始需要更清楚的表达。它们可以逐渐沉淀为任务范围、可用能力、完成条件、异常处理方式以及一组来自实际工作的验证案例。
这个过程并不要求一开始就建立庞大的治理体系。可以选一项高频工作，先确定它的结果、权限和接手方式，再观察哪些条件最容易被遗漏。
一次失败也可以成为下一次验证的材料。例如，曾经认错过两个同名客户，就加入对象消歧案例；曾经把超时当作未执行，就加入原操作恢复案例；曾经生成正确结果却无法交回，就加入交付格式与展示的检查。
《Towards a Science of AI Agent Reliability》将可靠性拆成一致性、稳健性、可预测性和安全性等维度。这也提醒我们，换个说法、再次运行或遇到异常时的表现，值得与一次成功一起观察。
模型、客户端和工具会不断变化，企业积累的工作标准则可以帮助判断这些变化是否真的带来收益。新模型写得更好，却增加了错误对象上的尝试；新流程速度更快，却让异常接手更费劲，都需要被看见。
这些标准无法脱离具体业务一劳永逸地制定。它们需要随着数据、权限和工作安排更新，也需要在真实运行中不断修正。
但正因为如此，它们具有组织资产的价值：人员或软件变化以后，企业仍然知道这项工作为什么这样安排，以及怎样判断它可以交差。
产业分工，会沿着这些工作条件继续展开
随着 Agent 能处理更多事务，企业软件的竞争可能会进一步延伸到结果交付、异常接手和组织成本。
模型厂商提供理解与生成能力，客户端或工作流组织步骤，业务系统维护实时事实和最终权限，身份、审批与执行控制则让委托条件进入实际调用。企业还需要为具体工作定义完成标准，并安排能够承担决定的人。
一家公司可以在一个产品中提供其中多项能力，也可以由不同系统协作。实际选择应考虑接入成本、可靠性和维护负担。
但无论产品怎样组合，工作关系都需要连续：目标不能在切换工具时丢失，业务身份不能变成模型随意填写的字段，审批要对应实际动作，恢复要回到原操作，交付要有足够的事实依据。
这也是我们持续关注 Agent-to-Business 的原因。Agent 进入已有业务系统以后，一段自然语言目标需要变成能够执行、核对和接手的业务结果。
ACC，即 Agent Capability Contract，尝试为业务能力开放与治理要求提供可移植的声明语言。百灵中枢 BailingHub 则将能力接入、可信上下文、审批与执行记录等条件落实到运行链路。在本地 Agent 场景中，任务编排仍由宿主承担，业务系统持有最终授权；企业自己的完成标准，也需要结合实际工作建立。
这些基础条件可以帮助团队在扩展能力时，保留对行动的判断依据。
回到假期后的工位，负责人真正希望看到的，是一份能够继续工作的交接：哪些已经确认，哪些仍待决定，原操作在哪里，以及下一步由谁负责。
AI 能独自推进的工作越多，企业就越需要知道，什么样的结果值得被组织认可。
当验收和接手不再需要从头重做，自动完成才更有机会转化为真正节省下来的时间。
