前几天我看到一个内部流程设计，第一反应不是兴奋。
是后背有点发凉。
这个流程很顺：业务在聊天框里说一句“帮我看下最近三周转化异常的渠道”，Agent 自动查指标、拉明细、生成分析，再给运营同学建一个待办任务。
演示时大家都点头。
这东西太像未来了。
可是我盯着流程图看了一会儿，脑子里冒出几个很土的问题：
它代表谁去查数据？
它能不能看用户明细？
它生成的待办，谁确认以后才算正式任务？
它判断错了，日志能不能查回来？
会议室里没人先问这些。大家更关心它能不能自动跑、能不能少开几次会、能不能让运营同学少写日报。
我理解这种兴奋。
但 Agent 进公司流程前，先得有人给它踩刹车。
Agent 不是更聪明的聊天框
这两年大家说 Agent，很容易把它想成一个更会办事的聊天框。
以前问模型，它给答案。
现在问 Agent，它可以调用工具、查数据库、写文档、发消息、建任务，甚至触发后续流程。
这一步变化很大。
聊天框答错，最多让人误会一段话。
Agent 做错，可能真的改了数据、发了通知、开了权限、推动了一个流程。
Microsoft 2026 Work Trend Index 里讲 Frontier Firm，把人和 AI agents 放在一起重新组织工作。这个方向当然值得看，但对普通公司来说，问题不会只停在“怎么让 Agent 提高效率”。
更现实的问题是：公司准备好让一个非人类执行者进入流程了吗？
以前公司流程里的每一步，背后都有一个人。
谁发起，谁审批，谁执行，谁复核，谁负责。
Agent 一进来，这些边界会变模糊。它可能用你的身份查数据，用系统账号调用接口，用模型判断下一步，还把结果推给另一个人。
看起来像是自动化。
往深处看，是责任链变长了。
第一个刹车：它代表谁
Agent 进流程前，第一个问题不是它能做什么，而是它代表谁。
代表业务用户？
代表数据团队？
代表系统服务账号？
还是代表某个部门？
这不是形式问题。
如果 Agent 以业务用户身份查数据，那它应该继承这个用户的权限。这个用户不能看明细，Agent 也不能看。这个用户不能导出敏感字段，Agent 也不能借工具绕过去。
如果 Agent 用系统账号执行任务，那更要小心。
系统账号通常权限更大，历史上也更容易被当成“先跑起来再说”的捷径。人用系统账号已经危险，Agent 用系统账号更危险。因为它调用频率更高，动作更快，出错后也更难解释“当时到底是谁的意图”。
所以 Agent 要有身份边界。
每一次查询、调用、生成和写入，都要能回答：
- 谁发起了这个请求；
- Agent 用哪个身份执行；
- 它继承了哪些权限；
- 哪些权限被明确禁止；
- 结果最后给了谁。
如果这几个问题答不上来，就不要急着把它接进真实流程。
第二个刹车：它能做什么
很多 Agent 演示喜欢展示一条龙。
查数、分析、写结论、建任务、发消息，最好还顺手生成一页汇报。
演示当然好看。
但公司流程里，能力越多，边界越要窄。
一个能查数的 Agent，不一定应该能导出明细。
一个能写分析的 Agent，不一定应该能直接发给客户。
一个能生成任务的 Agent，不一定应该能改任务状态。
一个能发现异常的 Agent，不一定应该能自动调预算。
这不是保守。
这是把“建议”和“执行”分开。
数据团队尤其要警惕一种场景：Agent 根据一段数据解释，自动推动业务动作。
比如它发现某渠道转化下降，于是建议暂停投放。听起来合理，但它有没有排除埋点异常？有没有看到活动周期？有没有检查库存和价格变化？有没有知道这个渠道本来就是品牌曝光，不按短期转化判断？
如果这些上下文没有进入系统，Agent 的建议可能很像一个刚入职但很自信的同事。
勤快，快，声音不小。
但不一定懂场子。
第三个刹车：谁来确认
不是所有动作都要人工审批。
如果 Agent 只是把异常指标整理成草稿，或者把会议纪要归档，完全可以自动做。
但只要动作会影响人、钱、权限、客户、对外信息，就要有确认环节。
这句话听起来像废话。
现实里最容易被跳过。
因为大家做 Agent 时，往往追求“少一步人工”。少一步当然爽，可是有些步骤不是低效，是责任。
比如：
- 给某个用户开数据权限；
- 向业务群发布指标异常结论；
- 修改一个生产报表口径；
- 给客户发送分析报告；
- 根据模型判断调整投放策略。
这些动作如果让 Agent 直接做，出了问题很难补。
比较稳的方式，是把 Agent 的产物分成三类。
第一类，草稿。它可以自动生成，但不能自动发布。
第二类，建议。它可以给理由，但需要负责人确认。
第三类，执行。只有低风险、可回滚、可审计的动作，才允许自动完成。
这不是让 Agent 变慢。
这是让它进入公司流程时，知道哪里该停一下。
第四个刹车：错了怎么查
Agent 最容易被忽略的不是权限，而是日志。
很多系统出问题，大家第一反应是看结果。
结果错了，重跑一次。
Agent 不一样。
它每次回答和执行，背后都有一串链路：用户问题、检索上下文、调用工具、生成 SQL、权限判断、模型输出、人工确认、最终动作。
只看最终答案，查不出问题。
你要能回放当时发生了什么。
它读了哪些数据？
用了哪个指标口径？
调用了哪个工具？
有没有触发拒答规则？
人工有没有确认？
最终动作是谁批准的？
这些日志不是为了追责好看，而是为了让系统能修。
没有日志，Agent 出错以后只能靠猜。猜来猜去，最后又会变成一句熟悉的话：“可能是模型幻觉。”
别什么都推给幻觉。
很多所谓幻觉，其实是系统没有留下足够上下文。
数据团队要提前进场
Agent 治理听起来像安全团队、IT 团队、法务团队的事。
确实是。
但数据团队不能等别人全设计完再进场。
因为 Agent 最先会碰到的，往往就是数据。
它要查指标，要解释异常，要拉明细，要生成报告，要把业务问题翻译成查询动作。
这些动作里，数据团队知道最多：
- 哪些指标不能混用；
- 哪些表早上还没更新；
- 哪些明细字段不该外传；
- 哪些异常只是埋点或补数；
- 哪些结论必须找业务负责人确认。
如果这些经验不进 Agent 的边界设计，Agent 迟早会踩到坑。
而且它踩坑的速度比人快。
最后
我不反对 Agent 进公司流程。
相反，我觉得它迟早会进去。
但公司不能只给它油门。
还要给它刹车、后视镜和行车记录仪。
油门是模型能力和工具调用。
刹车是权限、审批和拒答。
后视镜是上下文。
行车记录仪是日志。
少了这些东西，Agent 看起来会很聪明，跑起来也很快。
只是出了事以后，没人说得清它为什么那么做。
真正成熟的 Agent，不是每一步都自动跑完。
而是它知道什么时候该停下来，等一个人确认。
来源：
