从 Demo 到生产：企业 Agent 为什么需要 Runtime、评测与全链路治理

摘要：企业 Agent 的工程难点已经从 Prompt 和单次工具调用，转向长任务 Runtime、权限继承、业务结果验证、版本发布与持续观测。本文结合近期趋势，给出 ADP 4.0 + WorkBuddy 的落地路径。
搭建一个 Agent Demo 通常不难：模型负责规划，RAG 提供知识，Workflow 或工具调用执行动作。但生产环境会迅速放大四类问题：会话中断后任务能否恢复；知识检索和工具调用是否遵循员工权限；接口返回成功是否等于业务动作完成；Prompt、模型、Skill 或知识版本变化后，效果能否回归验证。近期行业进展说明，工程重心正在迁移。AWS 的 Managed Knowledge Base 将复杂问题拆解、迭代检索、文档级访问控制和流式 Trace 纳入托管能力；OpenAI Presence 强调最小必要权限、动作审批与人工接管；AWS 随后讨论 silent agent failures，即基础设施指标正常、任务状态显示完成，但业务结果实际错误或缺失。传统 APM 只能回答“服务是否存活”，AgentOps 还要回答“任务是否正确完成”。生产级 Agent 可以拆成四层。构建层连接模型、知识库、Workflow、MCP、连接器和 Skills；Runtime 层负责沙箱、Session、Memory、异步任务、恢复与状态同步；治理层负责身份、RBAC、凭证、审批、安全与审计；运营层负责评测、Trace、成本、异常聚类、版本比较和持续优化。四层缺一，Demo 都很难稳定复制到多个岗位。腾讯云 ADP 4.0 在 7 月 17 日以 AgentOps 为核心发布，覆盖构建、评测、集成、分发、治理、观测和优化。对工程团队而言，一个重要变化是可视化与 API 两条路径并存：业务可以快速验证，开发侧再把空间、应用、Agent、配置、发布、会话、对话和产出接入自动化链路。Claw 模式与云端沙箱支持长任务，Workflow、MCP、连接器、知识库和 Skills 负责能力组合，多 Agent 协作承接复杂任务分解。版本与权限同样关键。应用配置需要显式发布，版本快照便于追溯；企业、空间、应用三级权限和 RBAC 控制可见范围与操作边界；上线前用规则、模型或人工方式评测，上线后结合日志、调用链、性能、成本和业务结果继续优化。这里的核心不是“多看几个指标”，而是把任务完成标准纳入观测。WorkBuddy 则作为员工侧运行入口。员工可以在桌面、Office、移动端或 IM 中调用经过治理的能力，处理文档、知识检索、报表和跨工具任务。岗位经验可以封装为 Skills；连接腾讯文档、乐享知识库等资料时，既能检索引用，也能回写产物。涉及外部写入、删除、脚本或敏感能力时，保留二次确认，把高风险动作从自动执行改成可审批执行。实施时可以从三类任务开始：输入和输出边界明确、结果可以自动或人工验收、失败动作可撤回。先定义成功条件、超时与重试策略、人工接管点和审计字段，再逐步增加工具权限。不要先追求全自动，再补治理；治理本身就是任务设计的一部分。ADP 4.0 负责 Agent 的构建、Runtime 与 AgentOps，WorkBuddy 负责把能力放进员工真实工作流。两者把个人助手、岗位 Agent、部门 Agent 和跨岗位 Workflow 连成一条可发布、可观测、可持续迭代的工程链路。企业 Agent 的成熟度，最终不看 Demo 有多惊艳，而看任务能否稳定完成、错误能否被发现、能力能否被安全复用。标签：AgentOps、AI Agent、Runtime、MCP、Skills、Workflow、腾讯云ADP、WorkBuddy