Agenthof：用控制面让 AI Agent 的每次调用都有审计可查

大多数"受治理 Agent"演示之所以看起来受治理，是因为演示作者幕后操控了一切。Agent 按脚本说的调用工具、按脚本说的顺序调用，审计结果干净漂亮——因为根本没有其他可能。这只证明了管道的连通性，不能证明治理，因为治理只有在被治理的对象有自己的意志时才会发生。

所以我们把线拆了。

Agenthof 是一个面向 AI Agent 的小型控制面，只有一条规则：Agent 通过门（door）获得能力——model、tool、exec、spawn，每扇门都会授权调用、注入 Agent 从不持有的凭证，并写入一条绑定到启动本次运行的人的账本事件。用来驱动这些门的参考 Agent（LangChain，Python）原本是从固定脚本运行的。现在，一个真正的模型被赋予了 Agent 的实际能力作为工具——exec 门、spawn 门，以及其授权镜像对应的确切工具——然后逐轮决定调用什么。

不需要新增任何门。模型门只授权逻辑模型名称，重写为提供商的实际名称，然后原样转发工具调用对话的其余部分。因此一个 Agentic 循环就是更多受治理的模型调用，加上模型选择执行的任意 exec、tool 和 spawn 调用，每条都是独立的一手事件。Agent 不被信任；门负责治理它，无论如何。

运行它，对接你自己的 OpenAI 兼容提供商。脚本为父级运行打印 agenthof audit <run>。其头部显示 ledger integrity: verified (N events)；其下按顺序列出：每轮模型执行的 model fast — N prompt / M completion tokens 行；运营商运行时亲笔作证的一手 exec 事件；通过令牌交换以人类身份执行的 tool 调用，以及通过桥接运行时证明工具执行了的另一 tool 调用；以及两个 spawn 事件，每个都是拥有自己账本的子运行，链接到父级并绑定到同一个人。

如果模型请求了未被授权的内容，会有拒绝记录。当 exec 或 spawn 门拒绝时，Agent 告诉模型 refused by policy；当 tool 门拒绝时，模型被告知 door call failed。无论哪种情况，模型决定下一步怎么做，步骤仍可能成功。被拒绝的模型调用则会让步骤失败——因为没有模型可以询问。对接真实提供商时，最可能的拒绝是：速率限制被记录为 model fast refused — budget。

agenthof investigate --run <run> 随后将整个树打印为一条时间线，每个子节点的事件缩进在父节点之下。脚本对父级和每个子级运行 audit verify，退出时删除其工作目录。你的密钥在任何进程启动前从环境中移除，只能通过命令到达主机 agenthof 进程；Agent 从不接触它。

它不展示什么

它不展示隔离。这里的隔离舱是由测试替代程序启动的主机进程。Agent 能否自行访问提供商是运营商运行时的职责；项目有单独的、基于 podman 的证明来处理这件事。

它不保证结果。真实模型有差异；一次运行可能跳过某扇门、调用两次、或走另一条路径。承诺更窄：无论模型做了什么，都受到了治理且记录在账本上。循环的确定性证明是一个密封的 CI 运行，用固定的工具调用脚本对接同样的门。

而且 Agent 自己的报告不是证据。步骤产物——exec: …, tool whoami: …——是不受信任的 Agent 对自己的总结。证据是门事件，由 Agenthof 和运行时写入。如果它们曾经出现分歧，账本记录的就是实际发生的事。账本是只追加的且哈希链化：它能捕捉到未重算所有后续哈希的编辑、删除或重排序。在这些限制内它是防篡改的，不是防篡改的，文档对限制所在有明确说明。

Agent 有两层：一个框架中立的门层——针对已发布线缆协议的普通 HTTP 和 MCP，同时也定义了兩個门工具并发现授权的工具——以及一个薄薄的 LangChain 外壳，绑定这些工具并承载每个模型轮次。移植到另一个框架意味着重写外壳。门不知道也不关心是哪个框架在调用。对其他运行时和框架上构建的 Agent 的一级支持在路线图上标注为"更多 harness 适配器"；这一个的重点是它不需要特殊处理。

展示项目、密封 CI 运行和坦诚限制页面在仓库中，基于 Apache-2.0（标签 v0.1.0）。带上你的密钥，运行它，读审计报告——然后自己判断它证明了什么。