AI 智能体正在变成你的同事：企业架构必须为 “数字员工” 重写身份、权限与问责机制

过去一年，我参加了不少 "AI 落地" 的高层碰头会，几乎每次都能听到同一句话："我们团队已经全员用上 AI 了，Copilot、ChatGPT 都开了，提示工程也全员培训过了。"

几个月后再去追问，通常会安静下来。真正天天在用 AI 的，只剩一小撮工程师；试点项目大多还躺在沙盒里；至于 "AI 到底给业务带来了什么变化"，没人说得清。

问题不在工具不好用，而在衡量标准错了。能不能访问聊天机器人，和 AI 有没有真正嵌进工作流，是两码事。

十个工程师、其中一个人让 AI 稳定跑通一条生产链路，比一百人每人偶尔往对话框里粘一段文本要有价值得多。

这篇文章不聊模型又变强了多少，只想聊一个更接近地面、也更难解决的问题：当 AI 不再只是回答问题、而是开始动手办事时，组织的架构凭什么约束它？

从 “回答问题” 到 “动手办事”，工程问题彻底变了

"AI 助手回答问题" 和 "AI 智能体采取行动" 之间有道分水岭。

员工问一句 "这个客户的订单什么状态"，系统查一下资料、返回个答案，错了最多是员工做了个错误判断。

但把请求改成这样："检查订单，找出问题，联系客户，建立一张支持工单，如果符合条件就补发替换商品。"

到了这一步，它已经不是查资料了，而是要跟企业的真实状态打交道：要连客户库、订单系统、客服平台、邮件服务、财务规则、库存数据，甚至还要调用别的 AI 服务。

它得决定先调用哪个工具、按什么顺序调用，得在多个动作之间维持稳定状态，还得知道哪些动作要审批、哪些可以自动跑。最关键的是每一个动作都会产生后果。

这就是为什么我认为 "AI助手" 这个词已经不够用了。一个要 “动手” 的系统，架构上更接近组织里的一个员工或一个软件服务，而不是一个聊天框。

它需要有可识别的身份、明确的职责边界、有范围的访问权限、完整的生命周期、有效的监控，还得有人为它负责，并且组织必须能清清楚楚地说出：这个智能体可以干这个，但不能干那个。

而且这不是我一个人的判断，行业巨头已经用产品投票了。

• 微软在 Agent 365 里给每个 AI 智能体配了一个专属的 Entra 智能体身份（Agent ID），身份、生命周期、访问管理都一起管；
• 谷歌云的 Gemini 企业智能体平台里也有智能体身份、智能体网关、治理控制、拓扑和可观测性。

所以，企业 AI 的下一阶段，拼的不再是谁家模型更强，而是谁能围绕智能体把整套架构建立起来。

能力不等于权限，提示词从来不是安全边界

很多团队一开始容易犯一个错：把智能体当成一个 "匿名的进程"。

可传统软件是有身份的：服务有服务账号、应用有凭证、用户有账号、机器有身份、API 有鉴权。一个要干活的智能体，凭什么反而没有？

给它一个身份，权限边界才算有个落点。比如一个叫customer-resolution-agent 的智能体：

• 应该能查看订单信息、查看客服的历史记录、创建支持工单、发送预设的沟通话术、申请补发/替换、获取具体的库存信息

• 不应该导出整个客户数据库、访问工资单、修改财务记录、删除客户账号、调用任意外部服务

这里有个很容易被搞混的点：智能体的 "聪明程度" 不等于它的权限范围。 一个能力极强的模型，不该自动拥有极高的权限。

更要命的是第二个误区：拿提示词当安全边界。比如 "千万别泄露客户机密" 听着没毛病。

• 如果机密是通过文档、工具返回、检索结果甚至别的智能体悄悄进到上下文里的呢？
• 如果检索到的内容里埋了恶意指令呢？
• 如果某个外部网页让客服智能体干一件违反公司政策的事呢？

提示词可以描述规则，但它绝不能是执行规则的唯一机制。系统不能默认 "进入上下文的每段文本都可信"。

这需要模型负责推理和选择工具，基础设施负责身份、授权、策略执行和边界。

落实到代码上，大概是这样：

agent:
  name: customer-resolution-agent

permissions:
  read:
    - orders
    - customer_support
    - inventory

  write:
    - support_ticket
    - customer_notification

  conditional:
    replacement_order:
      requires:
        - order_status == "eligible"
        - replacement_value < 500
      approval:
        above: 500

  denied:
    - payroll
    - employee_records
    - customer_database_export

模型不是最终的策略执行点，运行时架构才是。这就是为什么 "智能体网关" 和 "集中式策略执行" 越来越重要的原因。

谷歌云的 Agent Gateway，就是一个在运行时管住智能体流量、对智能体和工具之间的交互强制访问控制的执行点。

智能体也得有 "工牌"：身份、所有权与生命周期

身份只解决了一半问题，另一半是所有权。

设想一家公司有 500 个客服智能体：有工程团队写的、有业务部门写的、有供应商交付的、有员工为内部流程自己搭建的、还有一批从临时实验 "转正" 到生产系统。

现在其中某一个做了个错误的决定，该由谁来负责？答案不可能是 "输入提示的那个人"。

组织必须能回答一串问题：谁创建的？谁批准部署的？业务流程归谁管？谁批的权限？跑的是哪个版本？用的是哪个模型？调用了哪些工具？访问了哪些数据？当时哪些策略生效？谁有权把它停掉？谁来审计它的访问？行为变了找谁？

所以智能体的身份管理，应该从一开始就是架构的一部分，而不是事后补救。微软的智能体身份治理文档里就明确写了：要为智能体指定一个人来负责，管理它的用途、生命周期决策和访问权限审查。

这个点尤其重要，因为 AI 系统不是静态应用。模型、提示、检索方式、工具、策略、周边数据一变，它的行为就会跟着变。上个月还安全的智能体，做一次大更新后可能就 "转性" 了。所有权必须在整个生命周期里一直有效。

工作流从一条线变成一张网：RBAC 为什么不够用了

智能体进入了生产流程，工作架构就变了。

传统工作流是一条直线：员工→ 应用 → 业务流程 → 数据库/API。

智能体工作流是一张网：员工→ AI 智能体 → 它再去调用别的智能体、内部 API、外部 API、知识库、企业数据库……

交互数量会指数级增长，架构也从 "请求-响应管道" 变成一张图，而图会带来全新的故障模式：

A 智能体调用了 B 智能体，B 智能体又调用了某个工具，该工具查询了数据库，数据库返回的是过时数据，B 智能体基于这个过时数据做了决策，而底层的业务状态早就变了。

这本质上就是分布式系统工程，只不过多了个 "概率决策" 的环节。超时、幂等、授权、版本控制、事务、可观测性、状态管理，一个都没少，AI 不是把这些难题消掉了，而是又叠加了一层新的复杂度。

基于角色的访问控制（RBAC）当然有用，但智能体引入了一些静态角色兜不住的新情况。一个员工有权限审批最高 5 万元费用，他的 AI 智能体该不该自动继承同样的权限？未必。

智能体可能需要一堆额外约束：能审批哪些费用类别？能审批自己 “老板” 的个人开销吗？能审批非工作时间的费用吗？能审批定期付款吗？金额超阈值了，怎么办？凭证不齐怎么办？申请涉及受限供应商时，怎么办？

到这一步，授权开始变得 "有情境"：

• WHO：哪个智能体

• WHAT：做什么动作

• ON WHAT：动哪个资源

• UNDER WHICH CONDITIONS：金额、风险、数据敏感性、工作流状态

• FOR HOW LONG：限时授权

• WITH WHAT OVERSIGHT：人工审批/自动策略/监控

不再只是问 "这智能体属于哪个角色"，而是问 "在当前时刻、对特定资源、在现有条件下，做这个动作合不合适"。这更接近高价值企业自动化该有的样子。

不是每个决定都该自主：先把边界划清，再谈自动化

谈到智能体，人们很容易把 "人类参与" 当成一种暂时的妥协。我觉得这个看法太简单了。人工审批不代表系统没实现自动化，有时它恰恰就是人为设定的一道 “闸”。

智能体完全可以自动干这些活：给请求分类、收集相关信息、核实资格、准备回复、计算推荐结果、给出行动方案。

但当来自财务、法律、安全、运营等方面的后果超过某个阈值时，最后那一步就该留给人。

而且，阈值不一定只能按 "操作类型" 分。它还可以看不确定性、数据敏感性、财务价值、业务影响，甚至看智能体对自己判断的置信度。

所以对 "自主性" 有个更务实的定义：自主 ≠ AI 想干什么就干什么，而是 AI 能在明确划定的权限边界内独立运行。 自主性越高，治理越要跟上。

可观测性要能 "破案"：追踪决策路径，而不是只看日志

这是我另一个看法被彻底改写的点。传统监控问的是：服务有响应吗？耗费了多久？API 报错了吗？有多少个请求失败了？

这些仍然重要，但对智能体远远不够。举一个我亲历过的场景：一个智能体顺顺当当跑完了一个工作流，HTTP 200，延迟1.8秒，基础设施零报错。

监控面板上一切正常。可它用的是错误的客户记录。系统完全按设计执行，却产出了错误的业务结果。

这意味着可观测性必须能追踪决策路径：

Request → 身份 → 策略评估 → 模型 → 检索到的上下文 → 选了哪个工具 → 工具执行 → 外部响应 → 智能体的决策 → 最终动作 → 结果

出事的时候，我得能完整复盘：智能体当时知道了什么？检索到了什么？为什么选这个工具？授权是怎么判断的？工具返回了什么数据？哪个模型版本做的决定？当时哪条策略生效？最后干了什么？

谷歌云的智能体平台就把身份、网关控制、追踪、日志、指标、拓扑、评估串在了一起。这已经不是应用监控，而是取证型的可观测性。

控制平面：让智能体可管理，而不是失控

把这些串起来，架构上会浮现出一个很清晰的东西：控制平面。

身份、策略、注册表、权限、安全、可观测性、审计、生命周期、评估、成本，这些都不该散落各处，而是围绕智能体形成一个统一的管理面。智能体在这个控制平面里运行，而不是自己当控制平面。

• 权限模型先行，再谈提示

• 先定义智能体能做什么、明确不能做什么

• 给它一个可识别的所有者+专属身份

• 访问权限尽量收紧

• 策略执行靠基础设施，不靠模型自觉

• 可观测性从第一天就设计进去

数据也在印证这不是杞人忧天。Gartner 预测，到2028年，33% 的企业软件应用会内嵌智能体 AI（这个数据在 2024 年还不到 1%），至少有 15% 的日常工作决策将由 AI 智能体自主做出。

但另一组数字更扎心：同样是 Gartner，预测到 2028 年会有超过 40% 的智能体 AI 项目因成本上升、价值不清或风险控制不足而被叫停；还有 70% 的企业会放弃那种由厂商 "驻场工程师"（FDE）代建、自己却改不动的智能体 AI。因为成本越来越高，内部又没能力去演进它。

这两组预测放在一起看特别有意思：AI 越来越普及是确定的，但普及的方式如果不对，注定要翻车。 翻车原因往往不是模型不够聪明，而是权限、治理、所有权这些 "地基" 没打牢。

五阶段成熟度：你的团队到底走到哪了

所以，该怎么判断一个组织对 AI 的采用是 "真" 还是 "假"？我倾向于用一个五阶段模型，从责任、整合、可靠性和控制四个维度看，而不是数有多少人能用聊天机器人：

有个很实用的自测：当开发者关掉对话窗口，系统里有没有任何环节因此发生改变？ 如果没有，那不管多少人用了 AI，组织都还停留在第一阶段。

• 阶段 1：解释代码、调 bug、生成 SQL、写文档、写正则、提测试建议。成本几乎为零，见效快，但 AI 对周围系统一无所知，上下文、执行、验证、集成全靠人。

• 阶段 2：AI 嵌进已有流程，比如写 PR 描述、准备代码审查、生成测试用例、给工单分类、编写发布说明、更新文档、生成日志摘要。它开始理解重复性任务的背景，但输出仍要人检查后再生效。这本质上是一种 "人机协作"。

• 阶段 3：AI 通过 API、Webhook、数据库、工单系统、CRM、CI/CD 管道真正接入系统。

这时候，架构设计的重要性开始超过提示工程，权限、鉴权、数据边界、日志、错误处理、兜底方案全都得跟上。很多 AI 项目就是死在这个阶段的。

• 阶段 4：AI 从 "生成输出" 变成 "产生结果"。智能体不再只是告诉你 "部署失败了"，而是会查监控、抓日志、跟已知事件比对、识别受影响服务、创建带正确元数据的工单、建议回滚、在动手前等人批准。

自主性不等于失控，反而要求更强的治理。

• 阶段 5：AI 成为运营架构的一部分。组织能随时回答：AI 做了什么、为什么允许它这么做、访问了哪些数据、成功没有、花了多少钱、要不要人介入、能不能撤销。

可观测性、审计、评估、可靠性、升级路径、成本监控、回滚、版本管理，都成了日常，而不是一次性的合规检查。

别数人头，数工作流：到底该看哪些指标

如果只谈理论就没用了。这是我实际建议工程负责人去盯的指标：

逻辑很简单：公司应该能讲清楚 AI 在运营层面改变了什么，而不是只汇报 "有多少人在用"。"

70% 的员工每周用 AI "适合放进董事会PPT；"AI 把平均分诊时间从 4 小时压到 20 分钟，错误率维持在 2% 以下"才能指导行动。数据暂时没有，就把它当假设目标写清楚，别拿没数的案例装数。

结语：自主性本身不是目的，设计得周全才是

最后补一句很重要的话：不是每个工作流都应该冲到第五阶段。

头脑风暴、架构讨论、探索性研究，最好就一直待在第一、二阶段，硬推到高阶段反而会把活儿干得更差。

只有满足 "重复性高、动作可衡量、输入数据结构清晰、错误可检测、权限范围受限、结果可撤销或可上报" 这些条件，更高的自主权才合理。

所以，现在值得问团队的问题，不再是 "你们用没用 AI"，大多数团队都在用。

真正的问题是：AI 到底进入了哪些业务流程？它被允许做哪些决定？可以自主执行哪些操作？成功怎么衡量？哪些环节需要人说了算？

能把这些问题答清楚的团队，才真正把 AI 从 "演示" 做成了 "运营"。AI 的成熟度，不取决于组织给了机器多少自主权，而取决于这份自主权设计得有多周全。

这比再做一个聊天机器人难得多，在我看来，这也正是未来几年最值得做的 AI 工程。