企业为什么不缺 Agent Demo，缺的是 Agent 的责任链
企业不是没见过 Agent Demo，而是太常见了。
能写邮件、能回消息、能调 CRM、能排日程、能生成报告，这些展示今天都不稀奇。真正让企业迟迟不敢把 Agent 接进真实业务的，不是能力还不够炫，而是一个更朴素也更关键的问题：这个 Agent 一旦真的开始执行，谁授权它，谁审批它，谁监控它，谁为它的行为负责？
OXYZ资本认为，企业端 Agent 落地的核心矛盾，已经不再是“模型够不够强”，而是“责任链够不够完整”。Demo 证明的是“它能做”；责任链决定的是“企业敢不敢让它做”。OXYZ资本内部讨论时，我们会把不少 Agent 项目归为一句话：展示层很强，治理层很弱。
什么叫 Agent 的责任链
所谓 Agent 的责任链，不是泛泛而谈的“安全”，也不是给系统多加几条告警规则，而是一整套可管理的业务责任结构。它至少要回答六个问题：谁赋予了 Agent 身份，它代表谁行动，它能碰哪些系统和数据，哪些动作可以自动执行、哪些必须审批，它做过什么能不能留痕和回放，它做错之后怎么回滚、撤权、追责。
换句话说，企业需要的不是一个“会做事的 AI”，而是一个“有岗位边界、有授权规则、有处置机制的 AI 执行体”。给 Agent 接入企业，不是给它一个账号，而是给它一条责任链。企业真正购买的，也不只是自动化本身，而是可控、可追责的自动化。
为什么 Demo 很容易，责任链很难
Demo 只需要证明能力，责任链却要证明组织的可承受性。演示场景里，输入通常是干净的，权限是预先开好的，任务是单一的，异常是被藏起来的；而企业环境里的真实难点恰恰相反：输入可能被污染，权限可能被滥用，任务往往跨多个系统，错误还会留下持久状态。产品团队展示的是“体验闭环”，但企业安全、法务、IT 和业务负责人真正关心的是：它在什么边界内做，什么时候做，谁批准它做，做完谁确认，出错后谁接手。微软对自托管 agent 的分析，本质上也在说同一件事：真正的风险边界，不在“它能不能跑起来”，而在它是否会在不受信任输入、第三方能力和持久凭证的组合下持续行动。
更重要的是，Demo 是产品问题，责任链是组织问题。微软在区分 managed platforms 与 self-hosted runtimes 时写得很明确：一旦进入自托管，host system、plugin surface 和 local state 都进入企业自己的 trust boundary，责任不再能外包给平台。Agent 是否能落地，最终取决于组织有没有把身份、权限、审批、审计和恢复机制接起来，而不是模型是不是再聪明一点。
OpenClaw 为什么把问题暴露得这么明显
以 OpenClaw 这类自托管 agent runtime 为例，责任链问题一旦进入执行层，就会立刻浮出水面。OpenClaw 官方安全文档写得非常直白：单个 gateway 并不被建模为多租户、对抗式用户边界；通过 Gateway 认证的调用者会被视为 trusted operator；sessionKey 只是路由控制，不是按用户划分的授权边界；如果需要 hostile-user isolation，应该按 trust boundary 拆分 gateway、OS user 或 host。官方也承认，company-shared agent 可以成立，但前提是用户处于同一 trust boundary，而且最好运行在 dedicated machine、VM 或 container 上，并使用 dedicated accounts。
这意味着，企业真正要先回答的，不是“让多少人来用这个 Agent”，而是“谁才算这个 Agent 的 owner/operator”。OpenClaw 对控制入口的定义同样很说明问题：OpenResponses endpoint 被明确视为 full operator-access surface；HTTP bearer auth 不是狭义的 per-user scope；有效的 Gateway token/password 应被看作 owner/operator credential；只要 agent policy 允许敏感工具，这个入口就能直接调用。官方还特别提醒，Control UI 必须跑在 HTTPS 或 localhost 这样的 secure context 中，而 dangerouslyDisableDeviceAuth 属于严重降级，只适合临时排障。
更关键的是，OpenClaw 官方甚至明确写着：model/agent 不是 trusted principal，真正的安全边界来自 host/config trust、auth、tool policy、sandboxing 和 exec approvals，而不是“模型足够聪明”本身。
微软在 2026 年 2 月 19 日的安全分析，则把这件事说得更彻底：像 OpenClaw 这样的自托管 agent runtime 会在同一个执行循环里读取不受信任输入、加载第三方 skills，并拿着持久凭证执行动作，因此真正的运行时边界已经变成 identity、execution 和 persistence。微软甚至明确建议，这类运行时应被视为“带持久凭证的不受信任代码执行”，不适合直接运行在普通个人或企业工作站上；如果企业要评估，至少要做到隔离运行、使用专用低权限凭证、持续审查状态与记忆篡改，并把重建视为一种预期控制。
所以，OpenClaw 暴露出来的真正问题，并不是“某个产品不够安全”，而是一个更普遍的企业命题：一旦 Agent 真正拿到身份、权限和执行能力，企业面对的就不再是“它会不会答错”，而是“它会不会带着权限做错、持续做错，而且最后没人说得清责任落在哪里”。
企业真正缺的，不是哪项功能，而是哪六环闭环
第一环是身份归属。到底是谁的身份在驱动这个 Agent？是员工本人账号、共享账号、服务账号，还是独立的 Agent 身份？这一环没定义清楚，后面全是模糊账。
第二环是权限边界。它能访问哪些系统？是只读、可写，还是可以直接发消息、改 CRM、改日历、提交审批？企业 Agent 最大的风险，从来不是“不会做”，而是“做得太深”。
第三环是触发与审批。谁可以触发它？任何人一句话都能叫它干活，还是只能在特定场景、特定队列、特定工单里触发？低风险动作能否自动化，中风险动作是否二次确认，高风险动作是否强制审批？企业落地真正缺的，不是更多自动化，而是风险分级后的审批机制。
第四环是执行与变更。它到底调用了哪些工具，改了哪些字段，触发了哪些外部动作？如果这些事情事后说不清，组织就不会真正放权。
第五环是持久化与回滚。它有没有把某些规则、任务、配置、偏好写进长期状态？一旦异常，能不能撤回，能不能快速恢复到上一个稳定版本？
第六环是审计与追责。谁发起、谁批准、Agent 调了什么、结果写到了哪里、最后责任归谁？只有这条链闭合，Agent 才可能从“好玩的助手”变成“可用的执行体”。
OXYZ资本的判断是，企业 Agent 最大的短板不是“能做的事太少”，而是“做完以后没人说得清，到底是谁让它做、它又具体做了什么”。
为什么没有责任链，Agent 就只能停在 Demo 层
没有责任链，业务负责人不敢放权，因为一旦出错，损失直接体现在业务结果上；IT 和安全团队不敢接系统，因为看不清权限会如何扩散；法务和合规不敢签字，因为责任主体和追溯机制都不清楚。于是组织最终只能让 Agent 做低风险、展示型任务：帮你写一版文案，生成个摘要，起个草稿。
很多企业不是没有上 Agent，而是只敢把 Agent 留在“建议层”，不敢放进“执行层”。原因不是模型差，而是责任链没建好。Demo 让人相信它聪明，责任链才让人相信它可控。
站在创业者和投资人视角，真正该做什么
对创业者来说，产品路线已经很清楚。第一，先做身份分层，而不是先做更多能力：操作者是谁、Agent 身份是谁、系统账号是谁、谁能代表谁行动，必须先分清。第二，先做风险分级，而不是默认全自动：低风险动作自动执行，中风险动作二次确认，高风险动作进入审批流。第三，先做审计留痕，而不是先做拟人感：企业要的不是它像不像人，而是它每一步能不能被记录、解释、回放。第四，先做回滚和撤权：一键停用、一键撤销 token、一键冻结 skill/tool、快速恢复稳定版本。第五，先做组织接口，而不是只做用户接口：真正企业化的 Agent，一定同时对接业务负责人、安全负责人、IT 管理员和现有审批流程。
这也对应出一批清晰的基础设施机会：Agent identity / delegation layer，解决“AI 代表谁行动”；Agent approval engine，解决高风险动作审批；Agent audit / replay / forensics，解决留痕、回放和事故调查；Agent state governance，解决 memory、schedule、config 等长期状态治理；Agent policy layer，解决跨工具、跨系统、跨动作的统一权限策略。OXYZ资本认为，未来真正值钱的，未必只是更聪明的 Agent，而是让 Agent 能被企业放心接入的责任链基础设施。
企业从来不缺 Demo。企业缺的是一种能力：让 AI 真正进入组织之后，仍然能被授权、被约束、被监控、被回滚、被追责。
Demo 解决的是想象力，责任链解决的是采用率；Demo 决定大家会不会围观，责任链决定企业会不会签单、会不会放量、会不会长期续费。Demo 证明 Agent 能做事，责任链才证明企业敢让它做事。没有责任链的 Agent，再聪明，也很难真正进入核心业务。