IT 服务台智能体

目标不是分流，而是动作，而动作就是风险。

大多数内部服务台试点都被划成一个检索项目：把 wiki 建索引、回答"我怎么连 VPN"、报一个分流率。这个版本三周就能上线，却几乎撬不动任何东西——因为真正吞掉你服务台产能的工单并不是问题。

• 划范围之前，先看你真实的工单构成。在多数组织里，按量排名靠前的类别是密码与 MFA 重置、访问权限申请、软件与许可证开通、设备故障，以及入离职任务。这五类里有四类以某个身份系统的变更收尾，没有一类是靠一篇文档回答的。
• 只会回答问题的智能体，是在和早已存在的搜索竞争。如果对话的结局是"这是那篇文章"，员工还得自己干活，而你的分流指标测的是有多少人放弃了。这与客服智能体掉进去的是同一个陷阱，区别在于内部用户无处可去，他们只会干脆不再用它。
• 价值曲线是不连续的。回答一个问题，省下员工一分钟。端到端完成一次访问申请，省下的是他被卡住的一整天，外加一名技术人员的一次上下文切换。这两个产品之间没有渐进路径——后者需要一套授权架构，你要么把它建起来，要么就没有。
• 按爆炸半径排序，而不是按频次。量最大的动作——密码重置——同时也是掌管你整个资产估值的那一个。从可逆、低权限的动作开始：许可证分配、通讯组成员、工单路由、状态查询，用它们把身份侧的管路跑通，而此时的失败模式只是尴尬，还不是入侵。

身份核验就是安全边界，而智能体在这件事上结构性地不如它所替代的那位技术人员。

人类技术人员脑子里跑着一个没写下来的"合理性"模型。时区不对、一位聊过很多次的同事忽然换了口音、异常的紧迫感、一个对不上的故事——这些都不在操作手册里，而它们全都在拦截攻击。智能体一样都没有，并且被优化成"对正在和它说话的任何人都乐于帮忙"——这正是社工目标的定义。

• 永远不要在对话里做身份核验。基于知识的问题——工号、上级姓名、入职日期、某个号码的后四位——一份 LinkedIn 档案加一张组织架构图就能答上来。如果核验发生在聊天里，攻击者的任务就只是"演好一名员工"，而这正是他们已经很擅长的事。
• 用带外通道核验，且绑定到已注册的因子上。推送到已登记的验证器、来自受管硬件的签名设备证明、发到在册号码的一次性验证码——这项检查必须是来电者所持有、并由系统验证的东西，而不是来电者所知道、并由模型判断的东西。
• 某个因子的恢复，绝不能由该因子的缺席来授权。"我手机丢了所以做不了 MFA"既是最常见的正当请求，也是攻击话术的原文。唯一安全的处置是：第二个已注册因子、由人工核验政府证件的视频通话，或线下当面核实。永远路由给人，并且把这条写进设计文档里，免得有人在第三季度把它优化掉。
• 把敏感动作绑定到一次升级验证上，而不是绑定到对话历史。会话开头的核验并不授权二十轮之后提出的某个动作——那时上下文里已经塞满了请求者自己选择输入的内容。要在产生变更的那一刻重新发起挑战。
• 把文字记录当作对抗性输入。服务台智能体读的是提问者写的文本，这是教科书级的提示注入面，而它手里握着通往身份提供商的凭据。消息里的任何内容都不得被允许扩大权限范围，而这是代码里的强制执行问题，不是提示词里的一句指令。

每个动作都按权限授权，权限从记录系统实时算出，绝不从请求里推断。

最重要的那个架构决策是：智能体并不持有管理权限、再自行决定何时使用它。它持有的是"代表某个已验证身份执行某个具体动作"的能力，而该身份能拿到什么，是被推导出来的，不是被判断出来的。

• 在请求发生时，从身份提供商与 HR 系统推导出允许的动作集合。角色、部门、上级、在职状态、地点。一个昨天就到期的外包人员必须什么都拿不到，而且智能体不该是知道这件事的那个组件——权限查询本身就该返回空集。
• 把审批建模成数据，而不是对话。如果某个请求需要上级签字，那么这份批准是上级在其已认证的系统里创建的一条记录。一个报告"你上级在 Slack 上同意了"的智能体是在凭空发明审批，而审计轨迹需要的是真的那一份。
• 按动作给智能体短时效、窄范围的凭据。一个"十分钟内可把某用户加入某个预批准组"的令牌，与一个拥有目录全域写权限的服务账号，是完全不同的安全姿态。这正是面向智能体的最小权限凭据的全部论点，而服务台是它回本最快的地方。
• 保留一份任何权限都无法满足的硬性拒绝清单。特权组、一切触及身份提供商自身管理面的东西、安全工具、财务系统、高管账号。这些永远只归人，把它们编码成 fail-closed 检查，意味着未来某次权限配置错误也打不开它们。
• 让每次变更幂等，并连同身份、证据与授权它的那条权限一起记录。重试是必然的——那四个叠加的重试源在这里和在别处一样成立——一个被加了三次的组成员只是吵闹的日志，一份被买了三次的许可证则是一张账单。

你的知识库是错的，而工单历史才是真正为真的那份语料。

每个 IT 组织都有一个 wiki，每个 IT 组织也都知道自己的 wiki 已经过期。把检索指向它，得到的是一个信心十足地推荐你去年就下线的 VPN 客户端的智能体——而且与人类技术人员不同，它没有那次迁移的记忆去推翻文档。

• 已解决的工单才是你的地面真值。它们记录的是真实生效的修复，发生在不久之前，由一个验证过它管用的人写下。把排名靠前的故障类别的处置记录挖出来，当作权威来源，让 wiki 退居背景。
• 给每一段被检索到的内容附上新鲜度，并让智能体看得见。一份两年前最后编辑、而资产上季度刚完成迁移的文档，应该带着这个事实被呈现出来，并且要指示智能体在两者冲突时优先采信近期的工单证据。参见知识截止与时间：不带日期的检索是系统性错误，而非偶发错误。
• 凡是与具体设备相关的事，环境状态胜过文档。给建议之前先读真实配置——操作系统版本、各类 agent 版本、组成员、近期变更、进行中的故障。"这个服务现在是不是正在故障"只是一次 API 调用，而它能正确回答相当大一部分文档根本碰不到的工单。
• 把回路闭上，让语料自己变好。当一张智能体解决不了的工单被技术人员修好，那份处置记录正是此前缺失的那篇文档。把它送回来——一个用自身空白反哺知识库的智能体，每周都在变好；不这么做的那个，永远停在上线那天的水平。

IT 有一半是物理世界的事，而智能体在那里的职责是尽早说实话。

设备管理类动作看起来像普通的工具调用，行为上却完全不是。远程擦除不可逆。强制重启会打断工作。配置下发要等设备下次签入才生效，而那可能是明天。至于一块鼓包的电池，再多自动化也解决不了。

• 把破坏性设备动作划成单独的特权档，需人工审批。擦除、锁定、证书吊销都应当无视权限、强制第二人参与，因为失败不可恢复，而那个正当的紧急场景——笔记本被偷了——同时也是攻击者的掩护故事。
• 说清楚这个动作到底什么时候才会真正发生。管理类动作是异步且最终一致的。一个在把命令排进队列时就报告"已完成"的智能体，在用户唯一在乎的那件事上撒了谎。先报告已排队状态，等设备签入后再确认。
• 快速识别出"解决不了"这一类，并且路由得体。硬件故障、需要物理接触、任何需要人手摸到机器的事。这里的失败模式是一段二十轮的对话，最后仍然要派单——而那张派单在第二轮就该开出来了；这比没有智能体更糟，因为它先烧掉了用户一个下午。
• 把诊断结论带进工单。智能体移交时，技术人员应当收到它已经拉取的设备状态、它尝试过什么、以及它排除了什么。这与打断与移交是同一套纪律：一次丢失了工作成果的转交，比一次更早发生的转交更糟。

量解决率与重开率；分流率会朝着你想听的方向对你撒谎。

分流率是工具默认就会报的指标，也是最稳定地奖励一个糟糕智能体的那一个。一段"员工放弃了、转头去私聊同事"的对话会被计为成功，而由此长出来的影子支持经济，在你拥有的每一块仪表盘上都是隐形的。

• 去记录系统里验证解决。组真的加上了吗？许可证真的分配了吗？账号真的解锁了吗？查下游状态，而不是智能体的自述——这就是结果 vs 轨迹之分，只不过在这个领域里结果是可查询的，因而没有任何借口。
• 追踪七天内的重开与二次联系。同一个员工再问一次同一件事，是"第一次的解决只是表面功夫"这件事最真实的可得信号，也是与人们在私密频道里如何评价这个智能体最相关的那个数字。
• 报告升级质量，而不是升级率。服务台智能体的低升级率是警报，不是成就。真正要紧的是升级过去时有没有带上下文，以及技术人员是否必须从头开始。
• 把安全路径单独埋点，并像审一项控制那样审它。统计身份核验失败次数、被拒绝的升级验证挑战、命中拒绝清单的次数，以及试图扩大权限范围的请求。这条序列是"有人正在探测你的智能体"的早期预警，它该按固定节奏摆到安全团队面前，而不是躺在季度回顾里。
• 盯每张已解决工单的成本，而不是每次对话的成本。一个每轮很便宜、却什么都没解决的智能体是昂贵的；有意义的比较对象是一个技术人员的全成本工时，而单位经济学正是这个论证能被诚实地做出来的地方。

相关：智能体身份与权限是地基，智能体威胁模型讲怎么画爆炸半径，安全运营智能体则是内部工具问题的另一半。