零信任已做，工单Agent要不要先建控制面？

只读先验价值，写回先补执行边界，共用需求明确再建平台；七问判断上线条件。

假设用1个关闭工具做工单 Agent 上线演练，批准后排队5分钟。你原有的零信任若只管登录和服务访问，这次写入仍要验对象权限。我选只读场景先跑，写回先补控制能力；完整平台可以晚一点。

后端验得出越权，才有立项前提

关掉一张工单，可能停止升级通知，也可能触发服务考核。真正改变决定的前提，是后端能否回答：谁委托这个 Agent，关闭哪张工单，允许改哪些字段，当前状态是否允许关闭。

PoC 里一次答错，通常还能由人筛掉。工具接入后，检索到的恶意指令可能诱导关闭操作；跨会话记忆可能串入另一部门的工单号；超时后的重试可能再次发送结单通知。新增的是行动路径和状态污染，原有权限设计也要跟着复核。

若旧接口只认一个共用服务账号，后端看到的就是这个账号，而非发起员工。把员工姓名放进调用参数，还要由可信服务验证来源。否则模型生成一个名字，就可能冒用另一人的权限。

工具一旦能改业务状态，授权就要落在实际执行前，并绑定对象和参数。

例如，准备2张待关闭工单：A归运维部，B归财务部。运维员工获准处理A后，只把工具参数中的工单号换成B。验收要求是B保持原状态、执行层留下拒绝记录，而非仅在聊天窗口提示“无权操作”。

适配层要查询权威的工单归属，并封住直达旧接口的路径。若两张工单都能关闭，应先修执行边界，再谈扩大试点。

如果现有零信任体系已经做到这一粒度，直接复用。若对象归属查不到、写接口又无法收口，就保留只读。平台采购解决不了旧业务系统的授权盲区。

▲ 换成财务工单后，执行层必须拒绝，工单状态保持不变

单场景先双轨，共用写权限再提平台

场景先行适合单部门只读助手：检索范围沿用员工的数据权限，缓存也按租户和权限隔离。先测“员工看不到的工单，助手是否同样取不到”。这条路验证业务价值快，后续接第二个业务域时，要承担策略抽取和接口重整。

平台先行适合已经确定多团队共用工具、凭证或高权限操作的企业。先交付共同的身份与策略接口，再接场景。平台承担值守、策略变更和故障处置，业务团队保留工单归属与状态迁移规则；否则每加一个字段都要排平台需求。

我更倾向传统企业从双轨过渡起步：先让1个部门的10名员工试用检索和处理建议，关闭仍走原工单界面。平台侧并行补授权与审计，暂时维护2个入口。若财务部也要复用关闭工具，就把共用身份与策略接口提到平台层。

过渡要有退出条件：对象级授权测试通过，批准的参数与实际调用一致，失败操作可定位、可补偿，才向 Agent 开放关闭工具。人工确认界面若只显示“是否继续”，却隐藏工单号和改动字段，仍然缺少有效的批准依据。

先建控制能力与先建完整平台，是两个建设范围。一个场景也要守住边界；出现跨团队复用需求，再把已验证的能力提到共用层。

▲ 双轨过渡先保留人工关闭，执行边界验收通过才开放写入

五层控制要落到执行端，别留在提示词里

身份层关联员工、Agent 工作负载和委托关系。任务排队5分钟，员工在第2分钟被撤权；执行时应拒绝，而非沿用入队时的许可。身份系统与业务服务要约定撤权如何传到执行端。

工具授权层管动作、对象、字段和状态前提。批准工单A的第12版后，人工把它更新为第13版；执行端应拒绝旧批准。执行端核对规范化参数与版本，再把版本条件和状态变更原子提交。

凭证层将长期凭证留在可信代理侧，模型只输出调用意图。给沙箱的令牌即使有效期只有60秒，也可能在这段时间被读取。限定目标服务和动作，并用换目标服务的请求测试是否拒绝。

运行时隔离层管文件、进程、会话状态和网络。固定工具可用较窄执行环境；运行生成代码时提高隔离强度。出口默认收紧，只按需放行模型服务和工具代理，另测一次绕过代理直连工单服务是否失败。

Kubernetes 的 NetworkPolicy 由支持它的网络插件执行，同方向的放行规则取并集。namespaceSelector 与 podSelector 放同一项是交集，拆成两项就扩大放行范围。验收从工作负载实测连接；域名与接口限制交给相应的出口控制。

审计层贯穿前四层，记录请求关联号、委托主体、策略版本、审批号、工具参数摘要和业务结果。凭证与敏感正文做脱敏；安全审计写到 Agent 无权修改的位置。否则清掉运行实例，也可能把唯一证据一起清掉。

这五层是包围实际调用的控制边界，知识库和工单接口仍负责业务读写。接入时逐项标明现有系统由谁承担，缺哪一项再补，少造一套平行身份或日志系统。

▲ 五层控制共同约束实际调用，审计贯穿而非事后补做

并存期最贵的缺口，是写入结果不明

例如，把客户端超时设成3秒，让后台在第2秒提交，再丢弃响应。此时“超时”只说明没收到结果。用同一个操作号发起2次重试，验收应只出现1次状态迁移、1条结单通知，并能查回原操作结果。

操作号作为幂等键，由服务端识别重复请求；同一业务意图重试沿用它。若同号却换了工单或参数，服务端应拒绝。幂等记录与业务写入要可靠关联，避免写入成功却没留下去重记录。

把工单版本或预期状态放进更新条件，与状态变更原子执行；匹配失败就返回冲突，重新确认。通知单独设计去重与补偿。查询原操作结果时，业务状态和通知投递记录要分别核对。

安全门槛按同一口径比较，建设顺序才有讨论价值。场景先行把维护分散给团队；平台先行增加公共依赖和值守负担；双轨增加并存期适配和交接工作。预算里要列这些人和责任，少用组件数量估算投入。

还要演练策略服务不可用：新的高风险写操作暂停，人工原流程继续可用。审计暂时不可用时，是否可用可靠缓冲承接，应提前约定；若无法保证授权和留痕，就停止自动写入。试点负责人要亲手验一次降级入口。

关闭工具的上线评审单

以下按“工单 Agent 开放关闭动作”评审。每问填测试记录位置和负责人；缺项保留只读或原人工流程。第6问的验收话术是：“丢弃响应后重试2次，状态迁移1次、通知1条；附操作号查询记录，负责人：工单服务维护人。”

1

谁发起、谁执行、谁委托？撤销员工权限后，排队写任务是否被拒绝？

2

哪些工单、字段和状态允许修改？换成其他部门工单号，由哪一处拒绝？

3

长期凭证由谁保管？沙箱拿得到什么，泄漏后怎样止损？

4

会话记忆、文件与网络怎样隔离？跨会话串号、绕过代理的测试是否通过？

5

审批是否绑定实际参数？能否用同一关联号查到策略版本和业务结果？

6

写入成功却丢失响应时怎样处理？幂等、原子状态校验和通知补偿是否实测？

7

第二个业务域接入时，谁维护共用策略？平台故障时，谁负责停写和人工接管？

只读且数据范围受控，先用场景验证价值；单一写场景先补足执行边界；共用需求已明确，再把控制面做成平台。把迁移触发条件写进立项，比一开始画齐目标态更有用。

工单仍靠共用账号写回，要不要开放 Agent 关闭权限？留言谈谈你的约束。

IT架构师联盟

面向企业架构师与技术负责人的专业号：讲企业 IT 架构的选型与演进，把关键决策的取舍和代价讲清楚。