将 Agent 纳入运行时治理的实践清单

Agent 从试验走向业务系统时，最容易被低估的不是模型效果，而是运行边界。

一个能够查询知识库、调用 API、更新工单的 Agent，本质上已经参与了业务执行。它会携带上下文、选择工具、发起调用、根据返回结果继续运行。此时如果仍只用“模型 + 提示词 + 工具”的方式理解系统，身份、权限、故障和成本就会散落在不同模块中，后续很难治理。

下面给出一份可用于设计评审或上线检查的实践清单。它不绑定具体模型或框架，重点是让 Agent 的运行过程可控、可回溯。

一、把 Agent 视为独立调用主体

首先需要明确：Agent 不是某个开发者账户的延伸，也不应长期共享一把项目密钥。

共享凭证在原型阶段方便，但会模糊调用归属。多个 Agent 共用凭证时，无法回答“这次请求来自哪个流程”“这个凭证该不该撤销”“异常成本应该归到哪里”。

建议在接入时建立独立主体，并关联以下信息：

• Agent 或服务标识；
• 所属项目、环境和责任人；
• 可用的模型或接口范围；
• 凭证签发、轮换和撤销规则；
• 预算、配额和速率限制。

凭证应在运行时按身份注入和校验，避免进入代码库、镜像和普通配置文件。这样做能让后续的审计、告警和成本归因有稳定的基础。

二、将工具访问拆成可执行的策略

Agent 能调用一个工具，不代表它应拥有工具的全部权限。

以业务系统接口为例，只读查询、创建记录、更新状态和删除或关闭资源的影响完全不同。策略设计应避免使用过于笼统的“允许访问某系统”，而要尽量落到动作和范围。

可以从以下维度拆解策略：

这些策略需要放在实际请求路径中执行。只靠部署说明、代码约定或上线前检查，无法覆盖后续的工具新增、模型切换和权限变化。

三、为 Agent 循环定义“收场方式”

Agent Harness 可以理解为连接模型推理和外部执行的控制层。它负责接收模型的下一步决策、执行工具调用、回填结果，并判断是否继续。

正常路径往往没有问题，真正影响稳定性的通常是异常路径：接口超时、模型响应异常、工具返回不符合预期、调用重复，或者模型持续尝试同一操作。

因此，Harness 需要提前定义任务如何收场：

1. 最大执行步骤与总时长；
2. 工具调用的超时、重试与退避；
3. 重复操作的幂等约束；
4. 模型和工具不可用时的回退方案；
5. 预算超限或策略命中时的暂停、终止或人工接管。

这类规则应独立于模型的临场输出。模型用于判断任务路径，运行控制层负责限制异常扩散。

四、用统一关联标识贯通观测数据

对 Agent 而言，“有日志”不等于“可观测”。一次任务可能涉及多轮模型调用、多次工具访问和多个外部服务，必须让这些记录能被串起来。

建议用任务 ID 或链路 ID 关联以下信息：

• 触发来源、调用主体和环境；
• 选择的模型、提供方、延迟和错误；
• 工具名称、调用状态与执行耗时；
• 策略命中结果和处理动作；
• 凭证别名、项目或租户维度；
• 用量、费用估算与异常告警。

这样在出现问题时，团队可以快速区分：是模型回答不稳定、工具依赖故障、策略阻断，还是工作流产生了无效循环。

五、把成本信号放回运行过程

Agent 成本与运行行为紧密相关。长上下文、多轮推理、工具重试和多 Agent 协作都可能改变消耗结构。

一个可操作的做法，是按项目、环境、逻辑模型、提供方或凭证别名做归因，并对预算阈值、失败率、高成本请求和用量增长设置告警。成本一旦能够关联到具体调用链，优化才不会停留在“换一个更便宜的模型”。

有时，真正需要优化的是重复调用；有时是上下文管理；也有时是某类工具失败后触发了过多重试。运行时数据能帮助团队判断问题发生在哪里。

上线前检查清单

• [ ] Agent 是否有可区分的运行身份？
• [ ] 凭证是否可轮换、可撤销，且不落入代码与普通配置？
• [ ] 工具权限是否已细化到动作、范围和环境？
• [ ] 策略是否在每次请求的执行路径上生效？
• [ ] 是否定义了超时、重试、循环、降级和人工接管规则？
• [ ] 是否可以还原一次任务的模型、工具、策略和成本链路？
• [ ] 是否对预算、限流和异常消耗设置了运行时控制？

结语

Agent 的上线不是把更多工具接到模型上，而是把一个具备外部执行能力的单元纳入既有的工程治理体系。先把身份、策略、失败路径、观测和成本这些基础层补齐，后续扩展模型、工具和工作流时，系统才不容易失去边界。