AgentOps 正在成为新热点：AI Agent 从 Demo 到生产，还缺什么？

AgentOps 正在成为新热点：AI Agent 从 Demo 到生产，还缺什么？

如果你也关注 Go、后端开发、AI Agent 与工程实践，欢迎点个关注。这里不只分享结论，也会持续记录踩坑过程、架构思路和真实落地经验，希望能与你一起进步。

过去两年，AI 应用的关注点经历了几次明显变化：

Prompt Engineering
    -> RAG
    -> Function Calling
    -> AI Agent
    -> Multi-Agent
    -> AgentOps

前几个阶段主要解决"模型能不能完成任务"，AgentOps 关注的则是另一个问题：

当 Agent 开始独立运行几十分钟甚至数小时、调用多个工具、修改真实业务数据后，我们如何保证它可靠、可控、可追踪、可评测？

这是我认为当前最值得关注的技术话题。

从近期行业信号看，Agent 已经不再局限于聊天窗口。OpenAI 在 2026 年 6 月公布的数据中提到，超过 70% 的抽样用户曾让 Codex 执行估计需要人类一小时以上的任务；高强度用户会并行调度多个 Agent。OpenAI：How agents are transforming work

与此同时，AWS 将 AgentOps 总结为治理与安全、构建与运维、评测、可观测性四个支柱；Google 则在梳理 MCP、A2A、A2UI、AG-UI 等快速增长的 Agent 协议生态。AWS：AgentOps production practice、Google：Developer's Guide to AI Agent Protocols

这些变化共同说明：Agent 的竞争正在从模型能力，进入工程系统能力。

本文不讨论如何再写一个 ReAct Demo，而是从生产实践角度拆解 AgentOps：它要解决什么问题，系统应该如何设计，以及 Go 服务中可以怎样落地。

---

一、为什么传统 DevOps 不足以覆盖 AI Agent？

普通后端服务通常有相对确定的执行路径：

请求 -> 参数校验 -> 业务逻辑 -> 数据库 -> 响应

只要输入、代码版本和依赖状态相同，执行结果通常也是确定的。我们可以围绕 CPU、内存、请求耗时、错误率和日志进行监控。

Agent 的执行路径则可能是：

用户目标
  -> 模型制订计划
  -> 查询知识库
  -> 调用搜索工具
  -> 修改计划
  -> 调用业务 API
  -> 子 Agent 接手
  -> 请求人工确认
  -> 继续执行
  -> 生成结果

这里增加了几类传统服务很少同时面对的问题。

1. 执行路径不确定

同一个任务运行两次，模型可能选择不同工具、产生不同步骤，甚至在不同位置终止。

HTTP 状态码为 200，只能证明接口成功返回，不能证明 Agent 正确完成了用户目标。

2. 运行时间显著变长

一次 Agent 任务可能持续几十分钟，期间经历模型限流、工具超时、Worker 重启和人工审批。

它不再适合绑定到单次 HTTP 请求生命周期。

3. 错误不一定表现为异常

数据库连接失败会抛出错误，Agent 选错工具却可能正常返回。

这类"静默失败"最难处理：

• Agent 给出了结构完整但事实错误的报告；
• 工具调用返回成功，但修改了错误的资源；
• 任务提前结束，却自称已经完成；
• 成本比预期高十倍，但没有任何请求报错。

AWS 在 2026 年 7 月发布的生产实践，专门讨论了如何发现健康检查无法捕获的 Agent 行为错误。AWS：Detecting silent agent failures

4. Agent 拥有真实副作用

当 Agent 可以发邮件、创建工单、提交代码、下单或转账时，一次错误决策不再只是回答质量问题，而是生产事故。

因此，AgentOps 不是把 DevOps 换一个名字。它是在现有 DevOps、MLOps 和安全治理之上，增加对"自主决策过程"的管理。

---

二、我们真正需要管理的不是一次请求，而是一次 Run

生产系统中，我更倾向于把 Agent 的基本运行单元设计为 Run，而不是聊天消息。

一个 Run 表示用户委托的一次完整任务：

Run
├── Input：目标、上下文、权限
├── Plan：当前计划
├── Steps：模型推理和工具调用
├── Checkpoints：可恢复状态
├── Approvals：人工审批
├── Artifacts：代码、报告、图片等产物
├── Usage：Token、模型和工具成本
└── Outcome：最终结果与评测

建议使用显式状态机：

stateDiagram-v2 [*] --> QUEUED QUEUED --> RUNNING RUNNING --> WAITING_APPROVAL WAITING_APPROVAL --> RUNNING: Approved WAITING_APPROVAL --> CANCELLED: Rejected RUNNING --> RETRYING: Retryable Error RETRYING --> RUNNING RUNNING --> SUCCEEDED RUNNING --> FAILED RUNNING --> CANCELLED SUCCEEDED --> [*] FAILED --> [*] CANCELLED --> [*]

这里有三个重要原则。

原则一：交互连接与任务生命周期解耦

用户关闭浏览器、SSE 断线或者网关超时，不应该直接取消 Agent。

接口只负责创建 Run：

POST /v1/agent-runs
Idempotency-Key: run_req_01K1...

{
  "agent_id": "code-reviewer",
  "goal": "检查这个 PR 的并发安全问题"
}

服务返回：

HTTP/1.1 202 Accepted

{
  "run_id": "run_123",
  "status": "QUEUED"
}

客户端随后通过查询、SSE 或 WebSocket 订阅状态。断线重连只恢复事件传输，不重新创建任务。

原则二：每个步骤都要持久化

如果只把上下文放在 Worker 内存中，进程一旦重启，任务只能从头执行。此前已经完成的工具调用也可能被重复执行。

至少应该记录：

run_id
step_id
step_type
status
input_hash
output_ref
tool_call_id
model
token_usage
started_at
finished_at

原则三：任务结果与执行尝试分离

同一个 Run 可能因临时错误执行多次：

run_123
├── attempt_1：模型限流，失败
├── attempt_2：Worker 重启，超时
└── attempt_3：成功

run_id 表示一次用户意图，attempt_id 表示一次后台执行尝试。这样才能在重试时保留业务幂等，同时记录每次失败的真实原因。

---

三、一套实用的 AgentOps 架构

我们可以把生产 Agent 平台分成四个平面：

flowchart TB U[&#34;用户 / 外部系统&#34;] --> G[&#34;API Gateway&#34;] G --> C[&#34;Control Plane<br/>Run、权限、策略、审批&#34;] C --> Q[&#34;Task Queue&#34;] Q --> R[&#34;Runtime Plane<br/>Agent Worker / Sandbox&#34;] R --> M[&#34;Model Gateway&#34;] R --> T[&#34;Tool Gateway&#34;] T --> B[&#34;业务系统 / MCP / A2A&#34;] C --> S[(&#34;Run Store&#34;)] R --> S R --> O[&#34;Observability Plane<br/>Trace、Log、Metric、Cost&#34;] O --> E[&#34;Evaluation Plane<br/>离线评测、在线评分、回归门禁&#34;] E --> C

1. Control Plane：决定 Agent 可以做什么

控制平面负责：

• Agent、Prompt、工具和策略版本；
• Run 生命周期；
• 用户身份与租户隔离；
• 权限和预算；
• 人工审批；
• 重试、取消和超时；
• 发布与回滚。

一个常见错误是把所有控制逻辑都写进 Prompt。Prompt 可以指导模型，却不是强制安全边界。

例如"未经确认不要执行转账"不能只写在系统提示词中。工具网关必须在代码层检查审批记录：

func (g *ToolGateway) Execute(
    ctx context.Context,
    call ToolCall,
) (ToolResult, error) {
    policy, err := g.policy.Resolve(ctx, call.RunID, call.ToolName)
    if err != nil {
       return ToolResult{}, err
    }

    if policy.RequireApproval {
       approved, err := g.approvals.IsApproved(ctx, call.ApprovalID)
       if err != nil {
          return ToolResult{}, err
       }
       if !approved {
          return ToolResult{}, ErrApprovalRequired
       }
    }

    if err := g.budget.Reserve(ctx, call.RunID, policy.MaxCost); err != nil {
       return ToolResult{}, err
    }

    return g.adapters.Execute(ctx, call)
}

模型负责建议动作，控制平面负责决定动作是否允许执行。

2. Runtime Plane：让任务可恢复、可隔离

运行平面负责真正执行 Agent Loop。每个 Run 最好运行在隔离环境中，并具备：

• CPU、内存、Token 和执行时间限制；
• 文件系统与网络访问范围；
• Secret 动态注入；
• 工具白名单；
• Checkpoint；
• 心跳和租约；
• 取消信号。

Worker 获取任务时可以使用条件更新：

UPDATE agent_runs
SET status = 'RUNNING',
    worker_id = :worker_id,
    lease_until = :lease_until,
    attempt_no = attempt_no + 1
WHERE id = :run_id
  AND (
    status IN ('QUEUED', 'RETRYING')
    OR (status = 'RUNNING' AND lease_until < NOW())
  );

只有受影响行数为 1 的 Worker 获得执行权。租约到期后，其他 Worker 可以接管崩溃任务。

不过租约只解决任务所有权，不能代替工具幂等。如果旧 Worker 暂停后重新恢复，两个 Worker 仍可能同时执行外部操作。

3. Tool Gateway：统一副作用入口

Agent 不应该直接持有每个业务系统的访问凭据，而应通过工具网关调用。

工具网关统一处理：

• 身份映射和最小权限；
• 参数校验；
• 幂等键；
• 超时、限流和熔断；
• 审批；
• 敏感数据脱敏；
• 审计日志；
• 返回结果裁剪。

对于写操作，可以使用稳定的工具调用 ID：

tool_call_id = run_id + step_id + tool_name

数据库增加唯一约束：

CREATE UNIQUE INDEX uk_tool_call
ON tool_executions (tenant_id, tool_call_id);

重复调用时返回第一次结果，不重新发送邮件或创建订单。

需要强调：编排层的 tool_call_id 不能替代领域幂等。例如支付服务仍应使用自己的商户支付单号。两层幂等解决的是不同边界的问题。

4. Model Gateway：模型选择、预算与降级

在生产系统中，不建议让每个 Agent 直接调用具体模型供应商。

模型网关可以统一完成：

• Provider 适配；
• 模型路由；
• 限流与并发控制；
• Token 预算；
• 缓存；
• 降级和故障转移；
• 内容安全；
• 用量记录；
• Prompt 与模型版本关联。

一次 Run 应明确预算：

type RunBudget struct {
    MaxInputTokens  int64
    MaxOutputTokens int64
    MaxToolCalls    int
    MaxDuration     time.Duration
    MaxCostCents    int64
}

预算不是仅供监控的标签，而要在执行前预占、运行中累计、超过阈值后真正停止任务。

---

四、可观测性：不仅要看报错，还要看 Agent 做了什么

传统服务常用 RED 指标：

• Rate；
• Errors；
• Duration。

Agent 仍然需要这些指标，但远远不够。我们还需要观察决策质量、工具行为和成本。

1. Trace 应覆盖完整决策链

一次 Run 的 Trace 可以拆成：

agent.run
├── model.plan
├── retrieval.search
├── model.decide_tool
├── tool.execute
├── model.reflect
├── approval.wait
└── model.finalize

每个 Span 至少关联：

run_id
attempt_id
step_id
agent_version
prompt_version
model
tool_name
tool_call_id
token_usage
cost
latency
retry_count
outcome

不要默认记录完整 Prompt、模型响应和工具参数，其中可能包含个人信息、业务 Secret 和客户数据。生产环境应采用字段分级、脱敏、采样和访问审计。

2. 需要新的 Agent 指标

除基础设施指标外，我们重点关注：

类型	指标示例
任务结果	成功率、放弃率、人工接管率
运行效率	平均步骤数、工具调用数、重试数
模型质量	无效工具选择率、格式错误率、幻觉率
工具质量	超时率、拒绝率、重复调用命中率
成本	每 Run Token、每成功任务成本、异常成本增长
安全	越权请求、敏感数据命中、审批拦截
恢复能力	Checkpoint 恢复率、僵尸任务数

"每成功任务成本"通常比"每千 Token 成本"更接近业务价值。一个便宜模型如果需要反复调用工具和自我修正，最终成本可能更高。

3. 记录决策证据，而不是只记录最终答案

发生问题时，我们需要回答：

• Agent 当时拿到了哪些上下文？
• 使用的是哪个 Prompt 和模型版本？
• 为什么选择这个工具？
• 工具返回了什么结构化结果？
• 哪个策略允许了这次操作？
• 是否经过人工审批？
• 最终产物是否通过评测？

因此，Prompt、Agent 配置、工具 Schema、知识库快照和策略都应该版本化。

OpenAI 在介绍内部数据 Agent 时，也将上下文、制度知识、运行时信息、权限和安全作为核心工程问题，而不是仅仅强调模型本身。OpenAI：Inside OpenAI's in-house data agent

---

五、评测：HTTP 200 不代表任务成功

AgentOps 最难的一部分往往不是部署，而是定义"什么叫做得好"。

评测可以分为四层。

1. Tool 级评测

验证单个工具：

• 参数是否正确；
• 权限是否生效；
• 返回结构是否稳定；
• 重复调用是否幂等；
• 超时和错误是否可恢复。

2. Step 级评测

判断某一步决策是否合理：

• 是否选择了正确工具；
• 是否遗漏必要上下文；
• 是否在无须调用工具时产生了调用；
• 是否在高风险操作前请求审批。

3. Run 级评测

关注整个任务是否完成：

• 最终答案是否正确；
• 产物是否满足约束；
• 是否引入副作用；
• 成本和耗时是否在预算内；
• 是否需要人工返工。

4. 业务级评测

最终还要回到业务价值：

• 工单平均解决时间是否下降；
• 代码合并后的缺陷率是否变化；
• 报告被采纳的比例；
• 人工处理时间减少多少；
• 每成功任务的总成本。

AWS 近期公布的一套 Agent 评测流水线案例，将错误结果从约八分之一降低到约五十分之一，并把问题发现时间从数小时缩短到数分钟。这说明评测不应只在上线前运行，而应进入持续交付和生产反馈闭环。AWS：Evaluating AI Agents production blueprint

5. 将评测加入发布门禁

一次 Agent 发布可能同时修改：

• Prompt；
• 模型；
• 工具描述；
• RAG 数据；
• 编排逻辑；
• 安全策略。

这些内容都应视为可版本化的软件制品。发布前运行固定评测集：

基准任务集
  -> 候选版本执行
  -> 规则评分
  -> 模型评分
  -> 人工抽检
  -> 与线上版本对比
  -> 达标后灰度发布

建议同时设置质量、成本和安全门槛，避免准确率提升 1%，调用成本却增长 300%。

---

六、MCP 和 A2A 很热，但协议不是治理方案

当前 Agent 协议生态非常活跃：

• MCP 解决 Agent 与工具、数据之间的连接；
• A2A 解决独立 Agent 之间的发现、协作和任务交接；
• A2UI、AG-UI 等协议尝试解决 Agent 与用户界面的交互。

Google 的协议指南对这些边界做了较清晰的梳理，并明确指出它们解决的是不同层次的问题。Google：Developer's Guide to AI Agent Protocols

但协议解决"怎么连接"，AgentOps 解决"连接以后如何可靠运行"。

接入一个 MCP Server 之前，仍然要回答：

• 它提供了哪些只读和写入能力？
• 使用谁的身份调用？
• 数据会不会离开租户边界？
• 工具 Schema 变更如何兼容？
• 调用是否需要审批？
• 返回内容是否可能包含 Prompt Injection？
• 如何限流、审计和撤销权限？

A2A 场景也一样。Agent 之间能够互相委派任务后，还需要：

• 委托深度限制；
• 总成本预算；
• 跨 Agent Trace；
• 身份和权限传递；
• 循环调用检测；
• 最终责任归属。

协议让生态变得开放，但也扩大了治理边界。

---

七、几个容易踩的坑

坑一：把所有规则都写进 Prompt

Prompt 是软约束。权限、预算、审批和数据边界必须由代码强制执行。

坑二：只监控接口错误率

Agent 可能在零异常的情况下给出错误答案。必须补充结果评测和行为指标。

坑三：失败后从头重跑

长任务从头重跑会重复调用模型和工具。应该从持久化 Checkpoint 恢复。

坑四：认为一个大模型可以解决所有任务

不同任务对推理能力、延迟和成本的要求不同。生产系统需要模型路由和预算。

坑五：多 Agent 越多越先进

每增加一个 Agent，都会增加通信成本、上下文丢失、故障点和调试难度。能够由确定性代码完成的流程，不应强行改造成多 Agent。

坑六：直接把生产凭据交给 Agent

Agent 应通过受控工具访问业务系统，并使用短期凭据、最小权限和完整审计。

坑七：只计算 Token，不计算任务成本

真实成本还包括搜索、代码执行、浏览器、向量检索、沙箱和人工审批。应以 Run 为单位汇总。

---

八、我们会怎样逐步落地？

如果现有系统还是一个 Agent Demo，我不会一开始就建设庞大的平台，而会按风险逐步增加能力。

阶段一：先把执行记录下来

• 建立 Run 和 Step 数据模型；
• 记录模型、Prompt、工具与 Token；
• 工具调用使用稳定 ID；
• 增加基础 Trace。

阶段二：让任务可以安全重试

• 引入状态机和任务队列；
• 增加 Worker 租约；
• 持久化 Checkpoint；
• 工具写操作实现幂等；
• 区分 Run 和 Attempt。

阶段三：增加生产控制

• 模型网关和工具网关；
• 权限、预算和人工审批；
• 沙箱和网络隔离；
• Prompt、工具、策略版本化；
• 告警与异常任务处理后台。

阶段四：建立持续评测

• 收集真实失败案例；
• 建立离线基准集；
• 上线前进行回归评测；
• 线上抽样评分；
• 将质量、成本和人工反馈用于下一版本。

这条路径的核心是先控制最高风险：真实副作用、不可恢复任务、成本失控和越权访问。

---

结语

AgentOps 之所以成为热点，并不是因为行业又创造了一个新名词，而是因为 Agent 的工作方式已经发生了变化。

当 AI 只生成一段文本时，我们主要关心答案好不好；当 AI 开始运行数小时、调用真实工具、与其他 Agent 协作并修改业务数据时，我们必须像运营一个生产系统那样运营它。

一个能进入生产环境的 Agent，至少应该具备：

有身份、有权限、有预算、有状态、可暂停、可恢复、可追踪、可评测、可审计。

模型能力仍然重要，但随着模型越来越强，真正拉开系统差距的会是外围工程：

• 能否为 Agent 提供正确上下文；
• 能否让每次工具调用安全可控；
• 能否发现没有抛异常的错误；
• 能否从失败步骤恢复而不是从头重跑；
• 能否持续证明新版本比旧版本更好。

下一阶段的 AI 应用竞争，可能不再是谁最快做出一个会调用工具的 Demo，而是谁能让成百上千个 Agent 在生产环境中长期、稳定、可解释地工作。