Agent 工程化实践系列（二）：云端 Agent 协作与 EvalOps 治理

本文是“Agent 工程化实践”系列第二篇，侧重点是运行与治理：当 Agent 已经具备可检索、可追溯的知识与代码上下文后，如何以云端服务形态支撑业务逻辑确认、规则解释、需求与方案辅助、测试设计、问题分析、代码定位和修复执行，并用 Trace 与 EvalOps 把行为纳入发布、观测和回流闭环。

系列说明

Agent 工程化不仅要解决“上下文从哪里来”，还要解决“Agent 能以什么形态对外提供服务、如何控制权限、如何观测行为、如何持续回归”。本文聚焦云端 Agent 协作与治理层，讨论业务问答与逻辑确认、研发辅助、MCP 知识能力、问题分析与修复执行，以及 Hermes Gateway、Hermes Agent Runtime、Profile、Skills、Langfuse Trace 和 EvalOps 如何共同支撑这些能力稳定运行。

1. 背景：从人工协作到云端 Agent 服务

在研发协作中，很多问题并不是“没人知道答案”，而是答案分散在文档、代码、历史排查、接口约定、需求记录、测试用例和个人经验里。一个真实请求可能是业务逻辑确认、规则口径解释、需求背景梳理、技术方案辅助、测试用例补全、代码位置定位，也可能是线上异常分析和修复。

知识与代码底座解决了“材料在哪里、如何检索、如何追溯”的问题；云端 Agent 要解决的是“如何把这些材料变成稳定可用的服务能力”。因此，重点不只是让模型回答问题，而是把知识查询、业务确认、研发辅助、代码定位、问题分析、修复执行和行为治理组织成一条可控链路。
典型挑战包括：

2. 对外能力形态：Agent + MCP

云端 Agent 体系对外可以拆成四类能力：业务问答与逻辑确认 Agent、研发辅助 Agent、MCP 知识能力、问题修复 Agent。它们共享同一套知识与代码底座，但权限、工作流和治理要求不同。

这些能力不是几套孤立系统，而是同一个云端运行时在不同 Profile 和权限边界下的不同工作形态。

3. 多角色协作：只读分析、研发辅助与修复分权

多角色协作的核心不是“多做几个 Agent 名字”，而是把不同风险等级的能力拆开。业务确认、需求辅助、测试设计、代码定位和代码修复可以使用相同的知识底座，但它们的权限边界应当不同。

这种拆分带来三个好处：

4. 云端运行时架构

云端 Agent 体系可以抽象为四层。这里保留 Hermes Agent、Gateway、Profile、Skills、MCP、Langfuse 等技术概念，因为它们描述的是可复用架构部件，不涉及具体业务身份或内部地址。

入口层负责把真实请求接进来；Gateway 负责入站鉴权、协议适配和 profile 路由；Hermes Agent Runtime 负责加载角色、调用工具、维护记忆和执行推理；工具与知识层提供可验证上下文；观测与治理层保证行为可追踪、可评测、可回流。

5. 运行时如何消费知识与代码底座

Agent 的回答和修复都应建立在真实上下文上，而不是只靠模型记忆。底层通常需要两类知识源：

在工具形态上，这两类知识最好通过 MCP 暴露给 Agent，而不是把文件路径、索引细节和检索策略散落在 prompt 里。

在真实协作场景中，推荐流程是先判断请求类型，再决定只读分析还是进入修复链路：

其中，代码修复必须隔离。常见做法是为每个任务创建独立 worktree 或临时分支，修复完成后通过人工 review，而不是让 Agent 直接改主干。

5.1 Skills：把“怎么做”沉淀成可维护资产

只靠系统 prompt 很难长期维护复杂操作流程。Skills 更适合承载“遇到某类任务应该按什么步骤走”的知识，例如：

Skills 本质上是行为资产，也需要版本管理、评审、过期治理和运行态一致性检查。很多 Agent 线上问题并不是模型本身失败，而是加载了过期 skill、错误工具说明或旧 profile。

5.2 Profile：一个 Runtime 多种身份

Profile 不只是显示名称，而是运行策略集合：

这也是多角色协作比“全能助手”更稳的原因：同一个底层 Runtime 可以因 profile 不同而具备不同的权限和行为边界。

6. 长记忆与安全边界

6.1 长记忆：跨会话不从零开始

团队级 Agent 需要跨会话记忆，但记忆不能乱写。一个实用模型是三层记忆：

此外，历史任务不一定要写入长期记忆。很多过程性信息更适合通过 session search 按需召回，避免记忆越写越乱。推荐原则：

• 稳定事实可以写入记忆。
• 过程性产出不写长期记忆。
• 敏感信息不写长期记忆。
• 用户明确要求遗忘时要能处理。
• 记忆命中应能解释来源或置信度。

6.2 安全与权限设计

Agent 工程化之后，安全边界必须前置设计。

安全不是让 Agent 什么都不能做，而是让每类能力都有清晰边界、观测和回滚路径。

7. 为什么需要 EvalOps

Agent 上线后，风险不只来自代码 bug，也来自 prompt、skill、工具 schema、MCP、权限策略、知识库、记忆、profile、运行环境和真实用户请求分布。传统 CI 通常回答“代码有没有测试过”。EvalOps 要补充回答：

EvalOps 的定位可以概括为：

把 Agent 从“能回答”推进到“可发布、可观测、可解释、可回归、可治理”。

7.1 Langfuse：EvalOps 的数据面

在这套体系里，Langfuse 不是一个可有可无的“日志面板”，而是 EvalOps 的核心数据面。它负责保存真实运行轨迹、评测数据集、打分结果和实验记录；EvalOps 则在这些数据之上做规则判定、门禁、人审和回流。

可以把关系理解成：

这也是为什么 EvalOps 不能只做一份离线报告：没有 Langfuse Trace，就看不到 Agent 到底调用了哪些工具、参数是什么、工具是否失败、最终回答有没有证据链；没有 Dataset 和 Score，就很难把“这次发现的问题”变成下次发布前可回归的契约。

7.2 EvalOps 具体治理哪些资产

EvalOps 不只看最终回答，它要管理一组行为资产：

7.3 Agent 输出到底怎么判好坏

一个 Agent 输出不能只看“最终文本像不像”。至少要拆成五个维度：

8. EvalOps 的两条主线

EvalOps 需要区分发布前门禁和上线后观测，不能混在一起。

Golden 通过不代表整体优秀，只代表没有踩已知雷。生产采样发现异常也不代表必须立刻改资产，它首先是线索，需要 trace 复核和人审。

9. 七层模型：EvalOps 如何工程化

每层都有边界：

10. Langfuse Trace：生产治理的事实层

如果只看最终回答，很多问题都无法判断。Trace 把一次 Agent 执行拆成可复盘链路：

• 用户输入
• 模型中间输出
• 工具选择
• 工具参数
• 工具结果
• 错误和重试
• 耗时和 token
• 版本和 profile
• 最终答复Langfuse Trace 的价值包括：

没有 trace 的“评测结论”通常只能停留在主观判断；有 Langfuse Trace 后，异常才可以被分层归因，并和 Dataset、Score、release metadata 串起来。

10.1 Langfuse Trace 里至少要记录什么

除了这些字段，还要明确两类健康信号：

10.2 不要把 Trace 指标直接当裁判

Trace 指标是诊断入口，不是天然判决。例如 repeated tool 很高，可能是真循环，也可能是合理的逐步下钻；latency 高可能是模型慢，也可能是某个外部工具或仓库同步慢；grounding 低可能是证据缺失，也可能这条请求本来不是知识问答。

正确做法是先用 Langfuse 指标找异常，再回到原始 observations 复核，最后决定修资产、修工具、修指标，还是标记为无需处理。

11. Release Guardrail：守住已知红线

发布前门禁不试图证明 Agent 全面优秀，只负责防止已知关键契约回归。典型门禁流程：

门禁应按失败类型处理：

12. 生产观测：异常不是判决，是线索

生产观测适合发现新问题，但不应该直接阻断发布或自动改资产。常见观测信号包括：

生产异常的正确流程是：

12.1 接入状态要分层表达

EvalOps 很容易被讲成“全自动质量平台”，但更稳妥的表达是分层接入：哪些已经进入硬门禁，哪些只是 observe-only，哪些还在规划中。

这个表的价值是避免过度承诺：EvalOps 已经能覆盖行为资产版本、发布前 golden、生产 trace 诊断和异常人审回流，但业务结果、记忆治理、评审模型校准仍应作为下一阶段能力。

12.2 Dataset 双源与 Review SLA

Dataset 也要治理。一个实用做法是“双源模型”：

生产异常不应自动进入 golden。正确路径是：生产 trace 先生成 proposal，附带证据、失败类型、建议回流方向和影响范围；人审通过后，再决定是修 prompt、修 skill、修工具策略、修指标，还是新增 Dataset case。

同时要监控 review SLA：proposal 如果长期无人处理，本质上就是“系统发现了问题但组织没有闭环”。可以跟踪待审数量、最旧等待时间、接受/拒绝/延期原因和已回流 case 数。

13. 一个典型治理案例

某次生产采样中，系统发现一条异常轨迹：链路很深、耗时较高、token 消耗明显偏大，并被评审模型标记为疑似严重重复工具调用。如果只看标签，最容易做出的错误修复是限制工具调用次数。但 trace 复核后发现，真实问题分布在四层：

这个案例的关键经验是：LLM-as-Judge 适合提出“可疑假设”，不适合直接给最终判决。指标高也不一定意味着行为错，必须先确认口径、分母和 trace 事实。更完整地看，这类案例会产生四类回流：

这也是 EvalOps 的价值：它不仅发现被测 Agent 的问题，也能反过来发现评测系统自己的指标缺陷。

14. 落地避坑

15. 本篇落地路径

不用一开始追求完整平台，可以按三阶段推进：

最小可行版本只需要五件事：

1. 把 Agent 行为资产纳入 Git 和指纹治理。
2. 维护少量高价值 case，覆盖正样本、负样本和边界样本。
3. 用真实 runtime 执行，而不是只 mock 最终输出。
4. 把 Langfuse Trace 作为事实源，记录工具调用和错误。
5. 生产异常必须先人审，再决定是否回流。

16. 总结

云端 Agent 的核心不是多一个聊天机器人，而是一套把知识、工具、角色、权限、记忆、观测和评测组织起来的工程体系。知识与代码底座让 Agent 的回答有依据；运行时与 EvalOps 则让 Agent 的执行过程可控、可观测、可回归。

多角色 profile 让 Agent 在不同场景下做合适的事；知识库和代码知识库让回答有依据；trace 让生产行为可复盘；EvalOps 让 prompt、skill、工具和策略变化可以被发布、被观测、被回归、被持续治理。

当 Agent 从个人工具走向团队基础设施时，真正重要的不是“这次答得像不像”，而是它能否长期被维护、被追责、被改进。