别再给 Agent 喂原始数据了：先测量，再推理

别再给 Agent 喂原始数据了：先测量，再推理

你的 Agent 是不是也经常"看到"不存在的问题？这篇文章可能会找到根因。

我曾经以为问题出在 Agent 上。

给它一份大型 JSON 导出，问一个合理的问题：哪些字段变了？哪些看起来有风险？上线前应该重点查什么？

它总能找到点东西。每次都找到点东西。

但它会漏掉关键字段，会过度关注无关紧要的值，会在 JSON 里幻觉出不存在的模式。它注意到一条看起来戏剧性的记录，却忽略了让这条记录有意义的整体分布。

于是试了常规修复方案：更严格的 prompt、更长的指令、更大的上下文窗口、更多示例。

真正的问题比这些简单得多。

我给 Agent 的是嘈杂的上下文。

不是坏数据，是坏上下文。

本文提纲

  1. Agent 上下文问题：复制粘贴式投喂的代价
  2. 原始数据不是上下文：一个根本性的认知错误
  3. 先测量，再推理：正确的工作流
  4. Vajra：一个 Rust 工具的实现思路
  5. 确定性为什么比你想的更重要
  6. 具体场景：GitHub 项目发布前的健康检查
  7. 这个方法的边界：Vajra 不解决什么

Agent 上下文问题：复制粘贴式投喂的代价

默认的 Agent 工作流，到现在还是太接近"复制粘贴"。

给 Agent 一个代码仓库。给它一份 JSON dump。给它一堆日志。给它一个半结构化文件的目录。然后让它推断结构、识别异常、检测漂移、保存证据、决定下一步做什么。

这听起来很强大，但这是一个糟糕的分工。

Agent 擅长的是解释、综合、规划和权衡分析。它不擅长的是：数清嵌套文档里有多少路径、计算值的熵、比较两个分布、检测类型不稳定、生成可重复的结构指纹。

这些工作应该交给无聊的软件做。可靠的软件。每次给出相同答案的软件。

当你把一份巨大的 API 响应、GitHub 导出、日志 dump、CSV 或源码树粘贴给模型，然后让它"找出重要的东西"——你其实在让模型同时做两件事：

  1. 测量数据（计数、统计、分布、异常检测）
  2. 基于测量结果进行推理（解释、规划、决策）

这是两件完全不同的事。把它们混在一起，就是你 Agent 表现差的核心原因之一。

一位评论者（Tae Kim，有 7 年 LLM Agent 生产经验）说了他的真实经历：在做 Graph RAG 的实体解析时，把原始文档 chunk 喂给 Agent，结果 Agent 把大部分上下文用来数实体出现次数，而不是推理实体关系。改为先预计算规范化的实体 profile + 置信度分数，再交给 Agent 后，推理质量有了质的提升。

这不是个例。几乎每个认真做 Agent 的人都踩过这个坑。

原始数据不是上下文：一个根本性的认知错误

这是大多数人反复犯的错误：把"模型能看到"等同于"模型能使用"。

它们不是一回事。

一份 5MB 的 JSON 导出可能装得进上下文窗口。但这不意味着它是好的上下文。其中大部分 token 可能是：重复的对象结构、重复的 ID、常见的时间戳、低信号的值、或者只有在聚合分析后才有意义的字段。

人类面对这种东西也会抓狂，Agent 也一样。

一个实际的例子：你的 Agent 收到这样一份 JSON，里面有 500 条 claim 记录。每条记录有 status、amount、provider、timestamp 等十几个字段。Agent 需要判断这批数据有没有异常。

如果你把 500 条完整记录全部喂进去，Agent 大概率会：
- 被某一条 amount 特别大的记录吸引注意力（"这条看起来可疑！"）
- 忽略 status 字段的分布偏移（reversed_manual 和 pending_external_review 这种稀有值才真正值得注意）
- 在 JSON 的嵌套结构里迷路，忘记关注类型不稳定的字段

但如果你先跑一遍测量，给 Agent 的是这样的信号：

Path: $.claims[*].status
Dominant type: string
Cardinality: 7
Entropy: 1.82
Rare values: reversed_manual, pending_external_review
Null rate: 0.00

Agent 立刻就知道：status 字段有 7 种取值，信息熵 1.82（中等偏高），有两个稀有值值得关注。它现在可以推理这些稀有值是否意味着业务流程出了变化，而不是在 500 条记录里大海捞针。

这就是"上下文工程"的本质：不是给更多数据，而是给更好的信号。

先测量，再推理：正确的工作流

正确的 Agent 工作流应该是这样的：

MERMAID_BLOCK_0

关键区别在于中间那一步：确定性分析。在 Agent 开始推理之前，先用确定性工具把原始输入压缩成证据包（evidence bundle）。

这个证据包应该包含：

  • 路径和类型：JSON 里有哪些字段，每个字段的主要类型是什么
  • 指纹：数据结构的稳定摘要，相同输入永远得到相同指纹
  • 熵和基数：每个字段有多少种取值，分布有多均匀
  • 异常值和稀有值：哪些值在统计意义上是异常的
  • Schema 漂移：两个版本之间，哪些路径增删了，哪些类型变了

Agent 拿到这些测量结果后，可以做它真正擅长的事：推理后果、判断漂移是否是有意为之、提出迁移计划、决定哪些证据应该写进报告。

摘要说"有什么变了"。仪器说"这条路径变了，这个值的分布移动了，这个类型不稳定，这是证据"。

Vajra：一个 Rust 工具的实现思路

dev.to 上的这篇文章介绍了 Vajra——一个用 Rust 写的 CLI 工具，正是为了解决这个问题。

Vajra 能分析的输入类型包括：
- 结构化数据：JSON、NDJSON、YAML、CSV、TSV
- 操作产物：Markdown、PDF 文本、CPU profile、strace 日志
- 代码仓库：通过 tree-sitter 解析的源码、GitHub 导出

它的目标不是模糊的总结，而是稳定的测量。

几个核心命令：

# 检查数据结构和类型
vajra inspect payload.json

# 统计分布和基数
vajra stats events.ndjson

# 检测异常值
vajra anomalies batch.json

# 比较两个版本的结构漂移
vajra drift baseline.json current.json

# 生成紧凑的证据摘要（可控制 token 预算）
vajra essence payload.json --profile ai --format compact-ai --budget 500 --redact

# 分析源码结构
vajra inspect src/main.rs --input-format source --lang rust --semantic-paths

# 项目治理健康度
vajra governance commits.json

--budget 500 参数值得注意：你可以控制输出的 token 预算，确保不会超出 Agent 的上下文窗口。--redact 参数用于脱敏——在发送给任何模型或外部服务之前，把敏感数据替换掉。

Schema 漂移检测的输出是这样的：

Removed path: $.member.coverage.plan_id
Added path: $.member.coverage.policy_ref
Type changed: $.claim.amount string -> number
Distribution drift: $.claim.status high
Severity: critical

Agent 拿到这个报告，可以直接说："plan_id 被替换成了 policy_ref，这是一个字段重命名还是一次业务逻辑变更？需要确认迁移脚本是否覆盖了所有调用方。claim.amount 从 string 变成了 number，下游解析逻辑可能需要更新。"

这比让 Agent 自己从两份完整 JSON 里肉眼比对，强了不止一个数量级。

确定性为什么比你想的更重要

Agent 系统在推理层已经是概率性的了。围绕它的工具不应该再增加不必要的随机性。

如果一个工具每次总结得不一样，Agent 的计划就会因为难以调试的原因而改变。如果一个分数无法分解解释，Agent 就说不清楚为什么给这个评分。如果漂移报告不稳定，CI 就没法信任它。如果指纹因为对象 key 排序不同就变了，工具测量的就是格式噪音而不是结构。

Vajra 围绕几条"无聊"的约束来构建：

约束 含义
确定性排序 相同输入永远得到相同顺序的输出
稳定指纹 不受 key 排序、空值、格式差异影响
显式路径 每个测量结果都关联到具体的 JSON path
可解释分数 每个评分都能分解为具体的子指标
Profile 驱动裁剪 通过 profile 配置控制输出粒度和 token 预算
不静默修改源数据 分析过程不会改变原始数据

这些不性感。但正是这些让输出可以作为可信的 Agent 上下文。

Agent 不只是需要更多上下文。它们需要能信任的上下文。

一位评论者（mote，做嵌入式多模态数据库的）补充了一个重要的点：确定性在边缘部署场景下尤其重要。在边缘设备上，你不能对同一份输入多次跑完整推理来"看看模型这次注意到了什么"。预先将数据分桶为类型化分布，给模型提供可以推理的对象，而不是让它自己去数——这在资源受限环境下是质的区别。

具体场景：GitHub 项目发布前的健康检查

假设你有一个 Agent，负责在发布前审查一个 GitHub 项目的健康状况。

天真版本：把 issues、PR、commits、releases 的完整导出全部喂给 Agent。它尝试从原始记录推断项目健康度。它可能注意到最近的失败，但错过了贡献者集中度。它可能总结 issue 标题，但忽略了过时的所有权模式。它可能产出一份自信的报告，但证据基础很薄弱。

Vajra 版本：先测量——

vajra ingest-github owner/repo --output .vajra/repo
vajra governance .vajra/repo/commits.json --format json > .vajra/governance.json
vajra core-team .vajra/repo/commits.json --format json > .vajra/core-team.json
vajra anomalies .vajra/repo/issues.json --format json > .vajra/issue-anomalies.json
vajra essence .vajra/repo/issues.json --profile ai --format compact-ai --redact > .vajra/issues.essence.json

输出给 Agent 的治理信号：

Bus factor: 2
Contributor concentration: high
One-commit contributor rate: 0.61
Most active author share: 0.44
Velocity trend: declining

Agent 现在不需要从头阅读所有记录了。它读测量结果，然后产出有证据支撑的风险报告：

  • 所有权集中：只有 2 个核心维护者，bus factor 为 2，任何一个离开项目就面临风险
  • 贡献者流失：61% 的贡献者只有一次 commit，说明社区参与度低
  • 活跃度下降：velocity 趋势下行，发布前需要确认是否因为冲刺结束还是项目本身在衰退
  • Issue 异常集群：发布前出现异常密度的 bug report，需要优先 triage

如果 Agent 建议采取行动，这个行动是可以验证的：生成的报告是否引用了正确的路径？相关异常是否消失了或者可以解释？迁移是否消除了类型不稳定？同样的输入经过重构后是否产生同样的输出？

这就是 Agent 需要的反馈循环。

这个方法的边界：Vajra 不解决什么

值得清醒认识到这个方案的边界。

Vajra 不替代判断。它能测量结构和分布，但不能决定一个异常是否在业务上重要。它能标记贡献者集中，但无法知道这是临时的发布冲刺、组织风险、还是小项目的正常状态。

紧凑摘要不是源数据的替代品。当审计可追溯性、法律审查或事故响应需要原始记录时，evidence bundle 不够用。你需要保留原始数据。

脱敏是运营策略，不是工具功能。--redact 参数能替换敏感字段，但"哪些数据需要脱敏"这个决策属于你，不属于工具。

核心观点不是消除人类或 Agent 的判断，而是停止把判断浪费在确定性工具能做得更好的工作上。

你的 Agent 是不是也因为原始数据太多而"犯糊涂"过？评论区聊聊你的解法。觉得有参考价值就点个赞，让更多做 Agent 的人看到这个思路。

参考文档与链接

原始文章
- Stop Feeding Agents Raw Data — dev.to 原文，作者 copyleftdev

Vajra 项目
- GitHub: nicholasgasior/vajra-rs — Rust CLI 工具，用于结构化数据的确定性分析和紧凑证据生成

Context Engineering 相关
- Anthropic: Context Engineering — Anthropic 关于有效上下文设计的工程实践
- Toby Lütke: Context Engineering over Prompt Engineering — Shopify CEO 提出的"上下文工程 > 提示工程"观点

Agent 数据预处理相关
- LangChain: Document Loaders and Transformers — LangChain 的文档加载和转换管线
- LlamaIndex: Node Parsers — LlamaIndex 的文档分块和解析策略
- Unstructured.io — 非结构化数据预处理平台，专为 LLM/Agent 场景设计

确定性分析工具
- jq — JSON 命令行处理器，轻量级数据查询和转换
- Miller — 类似 sed/awk/cut 的数据处理工具，支持 CSV/TSV/JSON
- VisiData — 终端交互式数据探索工具，快速了解数据分布

Agent 架构参考
- Anthropic: Building effective agents — Agent 架构设计最佳实践
- OpenAI: A practical guide to building agents — OpenAI 的 Agent 构建实践指南

作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

posted @ 2026-06-14 12:25  iTech  阅读(3)  评论(0)    收藏  举报