AgentFootprint：可查询的 agent 上下文因果轨迹

AgentFootprint：可查询的 agent 上下文因果轨迹

为什么重要

AgentFootprint 把 agent debugging 的对象从日志字符串推进到“每次 read/write/decision/tool call 之间的证据关系”。它明确提出第三类错误：代码和基础设施都没错，但模型因为错误上下文、错误工具描述、过期记忆或错误 steering 而做出错误回答。对 Hermes 和 LLM-Wiki 来说，这是 Context-Engineering 的关键补丁：知识库不仅要回答“存了什么”，还要能复盘“某次回答被哪些上下文影响”。

机制 / 一阶原理

传统 logs 是线性事件；AgentFootprint 的核心是把运行时事件连成 evidence graph。每个模型输入、工具输出、记忆读取、skill/steering 触发都成为可追踪节点；出错时不是 grep 关键词，而是查询影响链：哪个事实进入了 context，哪个工具结果被相信，哪个 steering 在第几轮生效。

与现有 wiki 的关系

它与 axisagentic-runtime-trajectory-framework 都强调 trajectory，但重心不同：AxisAgentic 更像长期运行/恢复/SFT export 的 append-only runtime；AgentFootprint 更强调 explainability 与上下文归因。它补充 Harness-Engineering 中的 claim receipts：不仅最终报告需要 receipt，模型形成结论的中间上下文也需要 receipt。

可执行启发

• llm-wiki 的重要 query / ingest 可以增加轻量 context manifest：本次读取了哪些 index/log/pages/raw，哪些网页失败，哪些候选被拒绝。
• wiki-vquery 命中不应只作为隐藏检索结果；重要回答应列出实际采用的页面，方便未来复盘上下文污染或漏读。
• 对 coding agents，除了 test pass，还应记录关键工具输出是否进入模型上下文、是否可能带 injection、是否被隔离或摘要。

失败模式 / 边界

完整因果轨迹会带来存储、隐私和 token/trace 管理成本。并非每个小任务都值得记录全量事件；Hermes 更现实的起点是对高风险写操作、发布、无人 cron、复杂 wiki ingest 记录最小 manifest，而不是全面替换现有日志系统。

写入记录

• 2026-08-05 09:00 CST：新增 AgentFootprint 来源页，聚焦 contextual error、evidence graph 和 llm-wiki context manifest。