Vigiles — audit/lint/test/eval for agent harnesses

Vigiles — audit/lint/test/eval for agent harnesses

为什么重要

Vigiles 把 agent harness 明确定义为“steering your agent 的 CLAUDE.md / AGENTS.md rules、skills、subagents、hooks”，并把它当成类似 ESLint / Lighthouse / npm audit 的本地工具来运行。它关注的痛点很具体：你写了一条规则、一个 skill 或一个 hook，但不知道 agent 是否真的看到、采用并遵守。

这对用户重要，因为 Hermes / llm-wiki 已经沉淀大量 workflow rules、skills、cron prompts 和 wiki 页面。如果这些规则只是“看起来存在”，但触发不了、相互冲突、hook 失效或 safety rule 没有执行，那么知识库和 skill 生态会制造 false confidence。Vigiles 的价值在于把 harness 从文档资产推进到可 audit / lint / test / eval 的工程资产。

机制 / 一阶原理

Vigiles 的 README 把工具动作拆成四类：

1. lint：CI gate on deterministic checks，例如 broken refs、tool contracts、dead hooks、skill collisions。
2. audit：lint checks + Safety ring + opt-in live checks（例如 MCP 是否连接、skills 是否触发）+ graded report。
3. test：检查规则是否被 agent 采用或执行，识别“guard 看起来存在但实际不起作用”的 false confidence。
4. eval：更接近 harness 行为评估，衡量规则、skills、hooks 是否产生预期效果。

一阶原理是：agent harness 的失败经常是静默失败。broken tool reference、skill collision、rule not enforced、secrets-exfil gotcha 这类问题不会自动报错；agent 可能继续工作，只是没有受到预期约束。因此，harness 需要像代码一样被 lint、像安全配置一样被 audit、像功能一样被 test。

与既有 wiki 概念的关系

• 对 Harness-Engineering：Vigiles 把 prompts/tools/hooks/skills 组成的 harness 变成可检查对象，补足“规则存在 ≠ 规则生效”的工程现实。
• 对 AGENTS.md-Context-Files：仓库级上下文文件不应只被创建，还应验证 broken refs、scope、adoption 和 enforcement。
• 对 External-Agent-Skills-Design-Patterns：skill 的触发、冲突、工具合同和安全边界需要机器检查，而不是只靠 README 评审。
• 对 Agent-Benchmarks：它提供了本地 harness benchmark 的低成本入口：先检查结构和采用，再做更昂贵的 LLM eval。
• 对 harness-score-maturity-scanner：Harness Score 偏 repo maturity scanner；Vigiles 更偏具体 harness artifact 的 audit/lint/test/eval，两者可形成结构评分 + 行为验证组合。

对 Hermes / llm-wiki 的可执行启发

1. 给 Hermes skills 做 artifact lint：检查 description 是否有强触发、是否有 DO NOT USE FOR、是否链接 references、是否有验证门禁、是否有安全边界。
2. 给 llm-wiki cron prompts 做 rule adoption audit：每日雷达 prompt 包含 orient、web first、raw hash、深度判断、写入记录、index/log、优化文章等要求；应在运行后机械检查这些要求是否真的被满足。
3. 区分 lint/audit/test/eval：不要把“文件存在”误认为“workflow 生效”。低成本 deterministic lint 可以每天跑；live checks 和 behavior eval 可按周或在大改后跑。
4. 把 false confidence 当成一类故障：比“没有规则”更危险的是“以为有规则但实际失效”。最终报告应暴露哪些 claims 有 receipt，哪些只是 best-effort。
5. 用于外部 skill 安装前审查：高 star skill / marketplace plugin 不能直接安装，先跑静态 lint + dependency/permission audit + 小样例 adoption test。

失败模式 / 边界条件

• 工具自身也可能 Goodhart 化：团队可能写出满足 lint 的空洞规则；仍需抽样行为测试和真实任务 eval。
• 跨 agent 兼容性难：Claude Code、Codex、Copilot、Hermes 对 rules/skills/hooks 的解释不同，audit 结果需要按 runtime 解读。
• 过度门禁会降低速度：对低风险临时任务，不应引入完整 audit；适合按风险路由。
• README 证据限制：本页基于 README，未运行 npx vigiles audit，也未验证其实际检测覆盖率，因此 confidence 设为 medium。

深度判断

值得 deep ingest，因为它直接指向 llm-wiki 自我优化的下一步：不再只在日报里“提醒要 orient / raw / index / log”，而是把这些要求变成可检查的 harness contracts。它与 harness-score-maturity-scanner、coder-eval-skill-evaluation-ci、Halo Record 所代表的方向一起，构成“结构扫描 → 行为测试 → runtime receipts → 回归评测”的 agent harness QA 栈。

写入记录

• 2026-07-22 09:00 CST：新增 Vigiles source 页，提炼 agent harness audit/lint/test/eval、false confidence、Hermes skill/cron prompt 规则采用检查。