Deloitte 的 2026 技术趋势研究称，89% 的企业 AI Agent 试点从未进入生产，仅 14% 做到组织级规模化。难点不在模型会不会回答，而在系统跑不稳、管不住、查不清，Runtime 与 Observability 正成为企业 Agent 底座。

做出一个能调用工具、读懂文档、生成结果的 Agent，今天已经不算特别难。真正困难的是让它连续运行几小时，跨多个系统取数，遇到错误能恢复，权限不会越界，出了问题还能找到完整执行轨迹。

行业数据正在把这个落差摆到台面上：Deloitte 的 2026 技术趋势研究称，89% 的企业 AI Agent 试点从未进入生产；Teradata 的调查显示，78% 的企业已有 Agent 试点，但只有 14% 做到了组织级规模化使用。失败点往往不在模型“不会回答”，而在于系统“跑不稳、管不住、查不清”。

这也是最近企业 Agent 平台开始强调 Runtime、Identity、Gateway、Browser Tools、Code Interpreter 和 Observability 的原因。Agent 进入生产以后，模型只是执行链条的一部分，底座才决定它能不能成为可运维的软件系统。

从 Demo 到生产，缺的是一整层工程能力

一个演示版 Agent 通常只需要：

用户问题 -> 模型规划 -> 工具调用 -> 返回答案

生产版则更接近：

请求进入

|

v

身份识别与租户隔离

|

v

任务编排与长会话运行

|

+–> 调用企业 API

+–> 查询数据

+–> 浏览网页

+–> 执行代码

|

v

策略检查、重试、超时、人工确认

|

v

全链路追踪、成本统计、结果交付

少了任何一环，系统都会在真实环境里暴露问题。短会话可能没法处理一夜完成的任务；凭据散落在提示词里会带来数据泄露；没有追踪记录，运维人员只能从最终答案猜测 Agent 做过什么。

Runtime：先保证任务活着

Agent 任务经常比一次 HTTP 请求更长。它可能需要等待外部系统、分批处理文件、重试失败工具，甚至在用户离开后继续执行。

Runtime 层要解决的不是“模型输出什么”，而是：

• 会话能持续多久；
• 任务中断后是否能恢复；
• 并发升高时如何扩缩容；
• 不同租户的计算环境是否隔离；
• 超时、重试和取消如何定义。

一个实用的任务状态至少应包含：

{

“taskId”: “agent-task-001”,

“status”: “running”,

“checkpoint”: “after_gateway_call”,

“retryCount”: 1,

“deadline”: “2026-10-11T18:00:00+08:00”,

“requiresApproval”: false

}

没有 checkpoint 的长任务，一旦进程重启，就只能从头开始；没有 deadline 的任务，失败重试可能变成无限循环。Runtime 应把这些规则变成系统状态，而不是让模型自己记住。

Identity 和 Gateway：权限要跟着动作走

Agent 最危险的地方，不是它会生成错误文字，而是它可能带着有效凭据执行错误动作。

Identity 层负责回答“它是谁、代表谁、能访问什么”；Gateway 层负责回答“这一次调用是否允许通过”。两者不能都塞进系统提示词里。

建议把权限拆成动作级别：

对于 MCP、浏览器工具和内部 API，网关还应做参数校验、目标域名限制、敏感字段脱敏和速率控制。不能因为模型说“这是用户要求的”就跳过策略检查。

更稳妥的凭据链路是：

用户身份

-> Agent会话

-> 短期令牌

-> 网关策略

-> 目标工具

令牌应短期、可撤销、按租户隔离，日志中不能直接打印完整密钥。对高风险动作，系统要在工具层再次确认，而不是只依赖模型是否理解了提示词。

Browser Tools 和 Code Interpreter：能力越大，边界越要窄

浏览器和代码解释器让 Agent 能够接触真实世界，也让风险从“生成错误内容”变成“真的执行了错误操作”。

浏览器工具至少要限制：

• 可访问的域名和路径；
• 是否允许登录态；
• 是否允许上传和下载；
• 是否允许提交表单；
• 是否允许付款、发帖或删除数据。

代码解释器则要限制文件目录、网络出口、系统调用和运行时资源。一个能执行 Python 的沙箱，不等于一个可以访问内网、读取环境变量和调用生产 API 的完整服务器。

对于批量数据处理，最好把输入文件复制到只读工作区，把输出写到单独目录，再由人工或后置服务完成发布。这样即使模型生成了错误脚本，也不会直接改写原始数据。

Observability：不看轨迹，就无法治理

生产 Agent 最终交付的可能只有一句话，但这句话背后可能包含几十次模型推理、工具调用、重试和分支判断。只保存最终答案，无法排查失败。

观测系统至少需要记录：

trace_id

tenant_id

agent_version

model

prompt_version

tool_name

tool_args_hash

policy_decision

latency

token_usage

retry_count

output_status

敏感内容可以脱敏或只保留哈希，但调用链不能完全消失。开发者需要知道 Agent 在哪个阶段超时、哪个工具返回了异常、哪一次重试改变了结果，以及成本主要花在模型还是外部系统。

这也是为什么“能跑通一次”不能作为上线标准。生产验收应至少包括：

1. 正常路径；
2. 工具超时和返回错误；
3. 重复提交和幂等；
4. 权限不足；
5. 恶意或越权输入；
6. 模型不可用时的降级；
7. 人工接管和任务取消。

平台底座能解决什么，不能解决什么

以 Amazon Bedrock AgentCore 这类企业级运行底座为例，Runtime、Identity、Gateway、Browser Tools、Code Interpreter 和 Observability 分别覆盖长会话、身份凭据、安全网关、外部交互、代码执行和运行观测。公开信息显示，它在中国北京和宁夏区域提供了相关能力，并支持多模型、开源 Agent 框架和 MCP 协议。

这类平台能减少企业自己搭建隔离环境、凭据托管、运行追踪和弹性扩展的工作量，也能让应用不必绑定单一模型。但它不能替企业决定：

• 哪些任务值得交给 Agent；
• 结果如何验收；
• 哪些动作必须人工审批；
• 错误数据如何纠正；
• 一次任务最多允许花多少钱。

托管底座解决的是“能不能稳定运行”，不是“Agent 是否真的有业务价值”。如果目标、工具和验收标准都不清楚，部署再完整的平台也只能更稳定地制造低价值结果。

从一个窄任务开始量产

Agent 生产化的起点不应该是“做一个万能助手”，而应该是一条边界清楚的工作流，例如：

• 自动整理客服工单，再由人确认回复；
• 检查代码变更并生成审查报告；
• 从内部知识库检索资料，生成带引用的初稿；
• 读取监控告警，给出排查步骤，但不直接改生产配置。

先把输入、工具、输出、权限、成本和人工接管点写清楚，再逐步增加并发和自治程度。衡量效果时，除了成功率，还要看人工接管率、误报率、平均恢复时间、每个任务的成本和审计完整度。

国内团队如果要接入海外模型或 Agent API，可以通过 Code80 减少账号和网络配置上的摩擦，但企业内网、凭据、审计和生产权限仍然必须由自己治理。

常见问题

为什么 Agent Demo 很容易，生产却很难？

Demo 通常只有单次请求和理想工具返回；生产需要处理长会话、并发、失败恢复、权限隔离、成本控制和审计。

Runtime 和普通容器有什么区别？

容器只是运行环境。Agent Runtime 还要处理会话状态、任务恢复、超时、取消、扩缩容和多租户隔离。

Gateway 能不能替代模型安全训练？

不能。模型层安全、工具层策略和基础设施隔离是不同层次，Gateway 只能控制经过它的调用。

Agent 日志应该保存什么？

至少保存版本、身份、模型、工具、策略决策、耗时、重试、成本和结果状态。敏感参数可以脱敏或哈希化。

什么时候适合引入托管 Agent 平台？

当团队已经有明确场景，但不想重复建设长会话运行、凭据管理、沙箱和观测能力时，托管平台更有价值。若场景和验收标准都没定义，应该先做小范围验证。

A: 国内用户可以通过 Code80 更方便地使用支持的模型，但生产系统的权限和审计边界不能交给渠道解决。