插件架构

智能体的闭环照常运行。HALO 只接收智能体记录的步骤，保存下来，再从它们之间的引用读出闭环。

插件由四个部分组成，智能体本身保持原样。HALO 不运行智能体，不包装它的模型，也不读取它的记忆。它通过 MCP 或普通 HTTP 接收智能体记录的步骤，再从这些步骤中读出闭环。

各个部分

部分	作用	位置
工具	九个 MCP 工具：六个用来记录闭环中的一步，halo_trace、halo_report 和 halo_guide 三个用来读取。每个记录工具都会检查，这一步只引用了同一智能体更早的事件。同一台服务器也通过普通 HTTP接收同样的事件。	halo/mcp/server.py
账本	按顺序保存每个记录下来的事件及其引用。事件从不修改或删除，所以报告总能追溯到智能体记录的内容。	halo/mcp/ledger.py，以及运行服务器的那台机器上的一个 SQLite 文件
分析	从事件之间的引用读出通路、证据步骤和等级。它不调用任何模型。	halo/mcp/analysis.py
报告	按论文表格的各行返回结果，每个单元格都附上背后的事件编号。	halo_report，或命令行中的 halo trace report

一步的完整过程

1. 智能体在闭环中做了一件事，例如发出一条它自己决定发的提醒。
2. 它调用 halo_act，附上一句简短的摘要，trigger 设为 self，并在 uses 中列出这次决策依据的观察和记忆。
3. HALO 检查 uses 中的编号都属于这个智能体，把事件存为 e5，并在回复中给出这些引用实现的通路：Channels: S→A, M→A.
4. 之后，用户回复说提醒来得太早。智能体调用 halo_outcome，并设 about: e5。
5. 有人查询时，halo_report 读取这个智能体的全部事件，返回通路、步骤和等级。

设计选择

• 含义由引用承载。 HALO 不解读摘要。通路、证据步骤或等级，只能通过事件在 uses 和 about 中写明的编号出现。事件模型给出了具体规则。
• 每个智能体一条轨迹。 事件按智能体名称分开保存，所以一个 dot 和 Grok Bot 可以共用一个服务器，各自的轨迹不会混在一起。
• 会话标记时间。 状态持久性指一次交互中保存的东西在之后的交互中被用到，所以每个事件都带一个会话标签，例如一次对话或一次唤醒。
• 不推断任何东西不存在。 缺失的通路记为“未观察到”。轨迹能说明什么解释了原因。
• 不用模型，不用密钥。 插件的行为是确定的，也不保存任何凭据。记录什么，由宿主自己的模型决定。

插件在 HALO 各模式中的位置

只读模式问的是，系统的来源材料是否报告了每条通路和每个步骤。运行模式问的是，切断其中一项，输出会不会改变。插件问的是，一个正在运行的智能体做过的事里出现了哪些通路和步骤。运行模式给出的证据最强，但它需要代码。插件可以用于闭源产品，它报告的等级之后还可以在只读模式下与产品文档对照核查。