你的 Agent 是不是也经常"看到"不存在的问题？这篇文章可能会找到根因。
我曾经以为问题出在 Agent 上。
给它一份大型 JSON 导出，问一个合理的问题：哪些字段变了？哪些看起来有风险？上线前应该重点查什么？
它总能找到点东西。每次都找到点东西。
但它会漏掉关键字段，会过度关注无关紧要的值，会在 JSON 里幻觉出不存在的模式。它注意到一条看起来戏剧性的记录，却忽略了让这条记录有意义的整体分布。
于是试了常规修复方案：更严格的 prompt、更长的指令、更大的上下文窗口、更多示例。
真正的问题比这些简单得多。
我给 Agent 的是嘈杂的上下文。
不是坏数据，是坏上下文。
默认的 Agent 工作流，到现在还是太接近"复制粘贴"。
给 Agent 一个代码仓库。给它一份 JSON dump。给它一堆日志。给它一个半结构化文件的目录。然后让它推断结构、识别异常、检测漂移、保存证据、决定下一步做什么。
这听起来很强大，但这是一个糟糕的分工。
Agent 擅长的是解释、综合、规划和权衡分析。它不擅长的是：数清嵌套文档里有多少路径、计算值的熵、比较两个分布、检测类型不稳定、生成可重复的结构指纹。
这些工作应该交给无聊的软件做。可靠的软件。每次给出相同答案的软件。
当你把一份巨大的 API 响应、GitHub 导出、日志 dump、CSV 或源码树粘贴给模型，然后让它"找出重要的东西"——你其实在让模型同时做两件事：
这是两件完全不同的事。把它们混在一起，就是你 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）。
这个证据包应该包含：
Agent 拿到这些测量结果后，可以做它真正擅长的事：推理后果、判断漂移是否是有意为之、提出迁移计划、决定哪些证据应该写进报告。
摘要说"有什么变了"。仪器说"这条路径变了，这个值的分布移动了，这个类型不稳定，这是证据"。
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，做嵌入式多模态数据库的）补充了一个重要的点：确定性在边缘部署场景下尤其重要。在边缘设备上，你不能对同一份输入多次跑完整推理来"看看模型这次注意到了什么"。预先将数据分桶为类型化分布，给模型提供可以推理的对象，而不是让它自己去数——这在资源受限环境下是质的区别。
假设你有一个 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 现在不需要从头阅读所有记录了。它读测量结果，然后产出有证据支撑的风险报告：
如果 Agent 建议采取行动，这个行动是可以验证的：生成的报告是否引用了正确的路径？相关异常是否消失了或者可以解释？迁移是否消除了类型不稳定？同样的输入经过重构后是否产生同样的输出？
这就是 Agent 需要的反馈循环。
值得清醒认识到这个方案的边界。
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人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。