深度解析：Hermes Agent决策过程与可解释性测评
要理解Hermes Agent为何选择某一行动路径，而非其他可能选项，就需要深入其内部决策链路。它并非一个黑箱式的响应生成器，其每一步推理、工具调用与状态更新，都留下了可供追溯的结构化痕迹。解析其决策过程，可以沿着以下五条关键路径进行。
一、技能文件（SKILL.md）溯源分析
每次任务完成后自动沉淀的SKILL.md文件，是还原决策逻辑的首要依据。这份文件以Markdown格式结构化地记录了任务目标、所用工具链、参数绑定关系以及执行顺序，相当于一份可供人工审阅的“决策日志”。它不依赖向量嵌入或模糊匹配，而是直接暴露了Agent的显式行为契约。
具体操作时，可以遵循以下步骤：
1. 进入 skills/ 目录，定位与当前任务时间戳最接近的SKILL.md文件。
2. 检查文件头部的 Objective 字段，确认原始用户意图是否被准确建模。
3. 逐行阅读 Steps 列表，比对实际执行中各工具调用的输入参数与文件中声明的变量映射关系。
4. 查看 Constraints 区域，识别是否存在硬性规则（例如“禁止调用Slack API超过两次”）导致了路径的剪枝。
二、记忆锚点（FTS5索引）回溯检索
Agent在决策时，会从FTS5全文索引中召回高相关度的记忆片段，并将其注入系统提示。这些被激活的记忆直接影响模型对当前状态的理解与行动优先级排序。因此，检索触发的记忆条目，就是隐性的决策依据。
要回溯这个过程，可以：
1. 在终端中执行类似 fts5_search.py --query “bug关键词 上周 Slack” 的命令，复现原始任务的记忆召回过程。
2. 检查输出结果中 score 值最高的前三条MEMORY.md条目。
3. 打开对应的MEMORY.md文件，核对其 timestamp 是否早于当前任务发起时间。
4. 比对条目中的 semantic_tag（例如“time_filter_applied”、“slack_rate_limit_observed”）是否与当前的决策偏差存在因果关联。
三、Honcho用户画像动态注入审查
Honcho辩证式建模生成的USER.md文件，在每次新会话启动时会作为冻结快照注入系统提示。其中包含了经过正-反-合融合后的用户偏好表达，直接约束了输出格式、工具选择倾向与解释粒度。这一层影响常常被忽略，但却是解释“为何用表格而非列表”这类细节选择的关键。
审查时，需要：
1. 打开 USER.md 文件，定位最新版本的 Synthesis 区块。
2. 查找包含 output_preference 或 tool_bias 的键值对。
3. 确认其中是否存在类似 “prefer_json_over_markdown: true” 的显式声明。
4. 检查该声明的 last_updated 时间是否覆盖当前任务周期。
四、KEPA提示反向传播轨迹追踪
当用户否定某次输出（例如回复“不对，重来”），KEPA机制会将该提示-响应对标记为负样本，并生成修正后的提示模板。这个模板会在后续同类任务中优先加载，从而改变决策的起点。追踪这条轨迹，就能识别出“为何这次没用旧方法”的原因。
追踪方法如下：
1. 进入 kepa/traces/ 目录，按日期筛选最近七天的JSON日志文件。
2. 在日志中搜索 “feedback_status”: “negative” 的记录。
3. 提取对应记录中的 prompt_id，并在 kepa/templates/ 目录中查找同名的.j2文件。
4. 比对该模板与默认提示模板（default.j2）在 system_message 区域的差异项。
五、执行时状态快照（State Snapshot）比对
Agent在每个动作执行前，都会写入state_snapshot.json文件，记录下当前的环境变量、已获取信息、剩余约束以及候选动作集合。这份快照是理解“为何选A不选B”的最细粒度证据，它反映了模型在特定上下文下的即时判断边界。
进行比对时，可以：
1. 在任务执行目录中查找以 state_ 开头且时间戳匹配的JSON文件。
2. 解析 a vailable_actions 数组，确认所有合法工具是否均已列出。
3. 检查 blocked_by 字段，识别是否存在运行时约束（如API配额耗尽、网络超时）强制排除了某些选项。
4. 比对 confidence_scores 字段中各动作的数值分布，确认最高分动作的得分是否显著高于次高分（通常差值≥0.3可视为显著）。