企业 Agent 把任务交给人工后，成本并没有停止。复核人员要读上下文、核查证据、补充判断，有时还要退回重做。如果成本表只记录模型调用，产品看起来很便宜，实际交付却可能被复核和返工拖住。但人工费用通常比调用账单更难收集：有人只记录处理开始和结束时间，有人按岗位估算费率，有些任务还没有完成。面对这些缺口，成本报告应该给出有依据的范围，同时说明范围覆盖了什么。

用户说“报表打不开，帮我处理一下”，Agent 很容易生成一串看起来完整的步骤：清缓存、换浏览器、检查权限，甚至重新授权。问题在于，它还不知道打不开的是页面、下载文件还是定时任务结果。此时步骤越长，越可能把用户带向无关操作。企业工作流需要一种明确的停止能力：证据不足时，只提出能改变下一步判断的问题，并把执行状态锁在等待中。这个设计比一句“信息不够请追问”的提示词更可靠，因为工具能否执行必须由程序控

Agent 遇到资料不完整的任务，很容易一次列出很多问题。用户被要求提供浏览器版本、截图、日志、账号资料和业务背景，却不知道哪一项真的影响处理。补问多了，处理未必更快，还可能收集不该收集的信息。补充信息建议应围绕下一项决定：为了判断什么，还缺哪条证据？模型可以发现缺项，负责人员仍要决定信息是否必要、收集方式是否合适，以及收到后能否继续推进。

一个 Agent 查询工单、检索手册、核对状态，再请人工确认，整个过程可能只展示成一条回答。如果财务记录只有最后一次模型费用，前面的工具成本会消失；如果把整个过程耗时折成人工成本，又会把机器等待算到人身上。多轮流程需要两套关联的账：一套记录实际调用费用，另一套记录人的有效投入。任务周期可以作为第三个视角观察体验，但不要混进前两者。

工单到了最后一轮，模型往往很容易写出“问题已解决，可以关闭”。关闭工单会改变后续跟进、统计和责任状态。让 Agent 起草关单建议是合理的，让一段总结直接成为关单依据，则需要额外的事实与规则。产品应明确哪些内容可以自动整理，哪些判断必须由负责人员作出。

企业 Agent 很容易产出一份像模像样的处理步骤：先检查配置，再清理缓存，最后重启服务。真正需要追问的是，谁能确认这套步骤适用于当前对象，谁有权接受中断风险，以及失败以后由谁恢复现场。对产品而言，“建议可生成”和“决定已作出”是两个状态。如果界面只放一个醒目的执行按钮，用户很容易把前者理解成后者。即便后台保留了审核记录，交互也已经在暗示系统替负责人完成了判断。

支持人员处理工单时，经常需要追问入口、错误提示和发生时间。Agent 可以把追问整理得更快，但也可能让用户重复提供系统已经知道的信息，或者索要一大堆与当前判断无关的材料。补充信息建议的目标应该很窄：找到阻碍下一步判断的缺口，生成最少的问题。问题是否发送、发送给谁、是否涉及敏感资料，由已有工作流负责。

图中界面、人物和记录为流程示意，不对应真实客户、真实工单或实际运行数据。人工接管率降低，不一定说明 Agent 更好用了。系统可能解决了更多问题，也可能少报了应该转交的风险；接管率上升也未必是退步，可能只是新增了明确的权限边界。指标必须能解释接管为什么发生、交给谁、之后发生了什么。先把人工接管定义为工作流事件：自动化流程因为规则、证据缺口、执行失败或明确请求，把任务责任移交给人工角色。模型说“建议

图中界面、人物和记录为流程示意，不对应真实客户、真实工单或实际运行数据。关闭工单是一个业务决定。用户没有回复、系统任务显示成功、客服已经发出说明，都可能让工单看起来“可以结束”，但它们证明的是不同事情。给 Agent 的任务应是整理关闭依据并生成建议，是否关闭由既有规则和负责人决定。产品上先把“问题解决”和“按规则归档”分成不同结果。这样既能如实向用户说明，也能避免自动关闭率被误读成自动解决率。

Agent 为一个问题连续查询几次工具，看起来只是多走了几个步骤。真正记账时，每轮模型判断、工具服务、重试和人工复核都有可能产生独立成本。如果只看最后一句答案对应的模型用量，就无法解释为什么同类任务的费用差异很大。成本设计先回答一个问题：一次用户任务从开始到终止，实际执行了哪些操作？不要先假定每个任务都应该有固定调用次数。链路可能因证据不足、权限边界或工具失败提前结束，也可能多轮收集信息后再继续。