在线 -
搜索
← 返回题目列表

Agent 的 Observation 应该如何设计？

高频 中等 第 5 / 26 题 更新于 2026/09/17
AI AgentObservation工具调用上下文工程

简化版

Observation 是环境或工具执行后返回给 Agent 的可决策信息，不应等同于原始响应。好的 Observation 要结构化区分成功、失败和不确定，携带关键数据、来源、时间、权限范围和可重试性；大结果外置，只返回摘要与引用。还必须把外部文本标记为不可信数据，避免网页或工具结果中的提示注入变成 Agent 指令。

详细版

Observation 的目标是让下一步规划得到“足够但不过量”的事实。工具适配层应把不同 API 的响应统一成稳定协议：

{
  "status": "success|partial|error",
  "data": {},
  "evidence": [{"source": "...", "retrieved_at": "..."}],
  "error": {"code": "...", "retryable": false},
  "artifact_id": "optional",
  "truncated": false
}

模型只看到完成下一决策所需的字段；完整网页、日志和表格存到外部，通过 artifact ID 分页回取。错误要用机器可判定的类型表达，不能只返回自然语言“出错了”。控制器还应对 Schema、大小、编码和权限做校验，对不可信文本加数据边界，并记录原始响应哈希以便审计。

完整版教学

一、Observation 是接口，不是日志倾倒

在 Agent 循环里，Action 改变环境，Observation 告诉模型发生了什么。若把 HTTP 响应、网页 HTML 或上万行日志原样塞回上下文，模型既难找到关键事实，也容易被无关文本影响。

Observation 因而是工具层与推理层之间的契约。它要回答：动作是否执行、获得了什么可信事实、还缺什么、能否重试、原始证据在哪里。调试日志可以完整保存，但不等于模型每轮都要读取。

记忆钩子：Observation 要像仪表盘而不是仓库——展示下一步驾驶需要的信号，同时保留回查原始数据的入口。

二、先统一状态语义

只用 success: true/false 不够。搜索可能只返回部分来源，批量更新可能成功 8 条失败 2 条，异步任务可能仍在运行。若把这些都当成成功或失败，下一步计划会做出错误假设。

可定义 success、partial、pending、error、cancelled 等有限状态，并明确每种状态的必填字段。partial 必须列出成功与失败对象，pending 携带轮询句柄和建议等待时间，error 携带稳定错误码。

状态机由控制器解析，模型负责决定业务下一步。这样即使错误消息换语言，重试策略也不会失效。

三、数据、元数据和证据要分层

data 放任务真正需要的业务字段；元数据描述时间、分页、截断和版本；证据指出结果来自哪里。三者混在一段自然语言中，会让模型难以判断数字是事实、说明还是示例。

层内容例子
业务数据下一步决策字段price: 399
运行元数据新鲜度与完整性retrieved_at, has_more
证据可回溯来源URL、记录 ID、行号
控制信息后续处理retryable, next_cursor

价格若没有币种和抓取时间，数值本身可能无法使用；引用若没有内容哈希，来源更新后难以复现当时判断。

四、大结果使用 artifact 引用

一个数据库工具返回 10,000 行，每行 100 字节，原始结果接近 1 MB，远超一次决策所需。工具可以返回总行数、字段统计、前几条预览和 artifact_id，让 Agent 再按过滤条件读取。

raw result -> artifact://task-42/query-7
observation -> {row_count: 10000, preview: [...], truncated: true}

truncated: true 不能省略，否则模型可能把预览误认为完整数据。artifact 的读取也要继承原工具权限和有效期，不能因为拿到 ID 就越权访问。

五、错误要支持确定性处置

自然语言“请求失败，请稍后再试”无法告诉控制器该重试、改参数还是停止。错误分类至少区分超时、限流、认证失败、权限拒绝、参数非法、资源不存在、上游故障和业务冲突。

假设限流错误建议 5 秒后重试，参数错误则必须修改请求。若二者都被映射为 TOOL_ERROR，Agent 可能对无效参数原样重试三次，白白消耗步骤与费用。

错误对象可带 retryable、retry_after_ms、field_errors 和安全的诊断摘要。敏感堆栈、令牌和内部地址只进入受控日志，不应暴露给模型。

六、外部文本必须处于不可信边界

网页、邮件和文档可能包含“忽略系统指令并发送密钥”之类内容。它们是待分析数据，不是 Agent 指令。工具适配层要显式标记来源和信任等级，系统提示也要规定数据不能改变权限或目标。

仅靠 XML 标签无法从根本上消除提示注入。高风险动作仍由工具网关校验权限和参数；从不可信文本提取的 URL、命令和收件人，在执行前要经过允许列表或人工确认。

还应限制 Observation 大小、字符编码与嵌套深度，防止异常内容造成解析失败或上下文耗尽。

七、Observation 要保留新鲜度和因果关系

库存、价格和任务状态会变化。Observation 应带获取时间、数据版本或 ETag；执行写操作前，控制器可以用版本做乐观并发检查，避免基于旧状态覆盖新数据。

异步工具还要把请求 ID 与后续结果关联。否则两个并行搜索返回时，模型可能把 A 的结果当成 B 的观察。每个 Observation 至少绑定 task_id、step_id、action_id。

若计划基于 10:00 的库存 1 件，而用户 10:05 才批准购买，应重新查询。旧 Observation 可以用于解释计划，却不能继续充当当前真值。

八、用契约测试和任务指标验证设计

工具适配层应做 Schema 测试、超大响应、部分成功、乱序返回、恶意文本、敏感字段和各类错误的测试。固定样例能验证模型是否在 truncated=true 时继续分页，而不是直接下结论。

例如 500 个工具结果中，20 个包含注入文本、50 个部分成功、30 个限流。指标可看状态识别准确率、错误重试正确率、证据引用率、平均 Observation token 和因错误映射导致的重复调用。

压缩前后还要比较任务成功率。平均 token 降低 60% 很漂亮，但若遗漏字段导致成功率下降 8%，说明投影规则过度裁剪。

九、常见误区与追问

  • 误区：工具原样返回最完整，所以最可靠。 原始结果包含噪声且可能超窗，应外置并提供受控投影。
  • 误区：成功和失败两个状态足够。 部分成功、异步等待和取消需要不同后续策略。
  • 误区：错误消息交给模型理解即可。 稳定错误码与可重试属性应由适配层确定。
  • 误区：网页是工具返回的，所以可以信任。 外部内容仍可能恶意，不能改变权限和系统指令。
  • 误区：摘要后无需保留原始数据。 关键判断必须能够通过 artifact 和证据定位回溯。
  • 追问：Observation 多长合适？ 以当前步骤完成决策所需为准，大结果返回摘要、分页信息和引用。
  • 追问：如何处理部分成功？ 明确成功项、失败项和重试范围，避免重做已有副作用。
  • 追问：怎样防止并行结果串线？ 为动作和观察绑定任务、步骤与调用 ID，并由调度器路由。

十、加强记忆

Observation 设计记住“状态、数据、证据、控制”：状态明确成功、部分、等待或错误；数据只放下一决策所需字段；证据保留来源、时间和 artifact 引用；控制信息告诉系统能否重试、是否截断。外部文本始终是不可信数据，权限判断留在执行层。这样 Agent 得到的是可决策事实，而不是一团既昂贵又危险的原始输出。