一个 Agent 在演示环境里能完成任务，并不等于它已经具备生产能力。
原型阶段，常见的工作流很直接：模型拿到上下文，选择一个工具，调用接口，再根据返回结果继续推理。这个链路足以验证“能不能做”。但当 Agent 接入内部知识库、工单系统、数据服务或自动化流程后，问题会从提示词和工具定义，转到身份、权限、失败处理、审计和成本。
这些问题的共同点是：它们都发生在运行时。
本文不讨论某个具体框架，而是梳理一套更通用的思路：把 Agent 当作能够调用外部能力的运行组件，为它补上明确的身份、可执行的策略、可观测的调用链路，以及实时的成本控制。
1. 为什么工具编排不足以支撑上线
工具编排解决的是“下一步调用什么”。它并没有天然回答下面几件事：
- 这个 Agent 以谁的身份访问外部系统？
- 它能调用哪些工具，又能执行到什么粒度？
- 调用超时、失败或重复执行时，系统如何处理？
- 这一次任务用了什么模型、调用了什么接口、消耗由谁承担？
如果这些约束只存在于配置说明或人工约定中，系统一旦开始迭代就会漂移。模型可能被替换，工具可能增加，某个流程可能从测试环境迁移到生产环境。原来的“默认允许”很容易变成隐性风险。
因此，生产环境的重点不应只是扩展 Agent 能力，而是让调用路径具备可检查、可限制和可回溯的特性。
2. 身份与凭证：让调用主体可识别
共享 API Key 是原型阶段最常见的选择，也最容易给后续治理埋坑。
一个共享 Key 无法区分是哪个 Agent、哪个应用或哪个环境发起了请求。它被轮换时，依赖它的调用都需要排查；它一旦泄露或需要撤销，也难以做到最小影响范围。
更适合生产环境的做法是为调用主体分配独立、可撤销的派生凭证，并在请求进入运行时后完成校验。这样可以把“人、应用、Agent、环境”放到同一套身份模型中。
一个最小可用的凭证边界，至少应包含：
- 调用主体：属于哪个 Agent 或服务；
- 有效范围：可用的环境、模型或接口；
- 生命周期：签发、轮换、撤销和过期；
- 用量约束：额度、速率或并发限制；
- 记录维度：后续审计与成本归因需要的标识。
凭证不应写入代码仓库或项目配置。项目配置更适合描述意图，例如选择哪类逻辑模型、在哪个环境运行；具体的密钥映射与注入交给运行时处理。
3. 策略要在请求路径上执行
“这个 Agent 可以访问工单系统”不是一个足够精确的授权描述。真正需要定义的是动作边界。
例如，对同一个工单 API，可以区分为只读、创建、更新、关闭等操作；再结合环境区分测试和生产；还可以为高风险操作设置审批或额外校验。
运行时策略通常需要组合多个输入：
- 调用身份和凭证状态；
- 当前环境与租户；
- 目标模型、接口和工具；
- 预算、配额与速率；
- 请求内容中的敏感信息或风险信号。
根据这些输入，执行层可以返回允许、告警、审计、阻断、脱敏、改路由或人工审批等结果。关键不在于规则数量，而在于规则是否真正位于每次调用经过的路径上。
如果策略只在上线前检查一次，后续的模型切换、权限扩展和工具新增都会绕开原有边界。
4. Agent Harness 应承担哪些运行职责
可以把 Agent Harness 理解为 Agent 的运行控制层。它不负责替代模型推理，而是负责管理“推理和执行如何衔接”。
一个基础循环通常包括：组装上下文、调用模型、解析工具调用、校验参数、执行工具、把结果回填上下文，并在结束条件达到后退出。
生产化后，Harness 还需要明确处理：
- 工具调用超时后的重试次数和退避策略；
- 同一调用重复执行时的幂等性；
- 模型或服务不可用时的降级和回退；
- 最大步骤数、总时长和总预算；
- 异常发生后是终止、人工介入还是交给补偿流程。
这些机制的作用不是限制 Agent 的能力，而是避免错误在循环中被放大。模型可以判断下一步，但不应承担所有运行控制责任。
5. 可观测性需要覆盖完整调用链
日志只是起点。对生产 Agent，更有价值的是可以串起来的调用链路。
一次任务应能关联任务标识、调用主体、凭证别名、模型与提供方、工具调用、策略决策、错误信息、延迟和成本事件。这样遇到问题时，团队不需要在模型日志、网关日志、应用日志和账单之间反复对照。
可观测性还会影响日常运营：
- 安全侧可以定位谁在什么时间使用了哪类权限；
- 研发侧可以定位失败发生在模型、工具、策略还是网络层；
- 业务侧可以观察不同流程的用量与效果；
- 平台侧可以发现高成本请求、异常增长或失败率上升。
真正难的不是“记录更多日志”，而是让身份、策略、调用与成本能够用同一个关联键连接起来。
6. 成本治理应进入运行时
Agent 的成本不是单一模型账单。长上下文、频繁重试、多步骤规划、多 Agent 协作都可能改变实际消耗。
只在月底对账，通常只能看到结果，无法及时处理异常。运行时更适合按项目、环境、逻辑模型、提供方和凭证别名归因，并结合预算阈值、速率限制和异常检测提前暴露问题。
成本归因的价值不只是控制花费。它还能帮助判断某个流程是否真的值得继续优化：是模型选择不合适，还是上下文过长；是工具失败导致重试，还是某个 Agent 的设计本身存在无效循环。
结语
生产级 Agent 的核心不只是“会调用工具”，而是每一次调用都能被识别、约束、追溯和计量。
在系统设计上，可以先从一个小闭环开始：为 Agent 建立独立身份，给高风险工具设定明确动作边界，记录贯穿模型与工具的调用链，再把预算和异常检测接入运行时。这样做不依赖特定框架，却能为后续扩展多个模型、工具和 Agent 打下更稳的基础。
