IntentFlow：通过编译后的策略与可审计的追踪机制来管控大语言模型智能体

想象这样一个大型语言模型代理：它能读取GitHub上的问题，搜索相关代码库，起草回复；由于有人急于处理，它便直接发布回复并关闭问题。最初的提示词中设定了约束：绝不能关闭问题，必须始终提供证据，遇到不确定的情况要询问人类。但模型还是关闭了问题。

这并非出于恶意。用文字写成的约束只是建议，而当问题描述措辞巧妙时，模型有时会将这些建议视为可选项。当安全审查员要求提供证明以确认该代理从未执行过禁止的操作时，现有的只有由同一代码路径生成的、按某种人为设定的格式编写的应用日志。那并非证据，只是一本日记而已。

IntentFlow是一种为填补这一空白而设计的实验性语言。

治理机制通常所在之处

大多数代理治理机制都存在于以下三个位置之一，而每个位置都会存在漏洞：

• 在提示词中。那是模型可能会忽略的散文式文字，唯一的审核方式就是查看最终输出并寄希望于其符合要求。
• 在应用代码中。这才是真正的强制措施，但策略如今与调用模型的 Python 代码混在了一起，而“智能体被允许做什么？”这个问题则需要通过查看代码库来回答。
• 在框架的回调函数堆中。函数之间相互关联，而策略则存在于某人的脑海中以及临时的日志记录中。

目前缺失的是一份可供审查的文档，用以明确可接受行为的范围：智能体必须具备的证据、它可以采取的行动、绝不能采取的行动、何时需要人工介入以及如何检查其输出。这样的文档应在模型之外得到执行，并留下任何人都能独立验证的凭证。

一段文字概括核心思想

IntentFlow是一种小型声明式语言。一个.iflow文件会明确说明目标、证据要求、行动策略、验证规则、不确定性处理方式以及带类型的输出规范。编译器会将该文件转换为JSON格式的执行计划，随后由包含13个阶段的运行时来执行该计划，同时所有工具调用都会通过ActionGate进行，包括从磁盘读取证据的操作。该门控机制会参考已编译的策略，而不会读取模型输出，因此模型无法通过欺骗手段绕过它。每次运行都会生成带有哈希链的追踪记录，可选择添加签名。之后intentflow audit会根据源文件重新构建规则，并验证运行过程是否遵守了这些规则。它只需要该文件和追踪记录即可，无需信任运行时、后端或模型本身。

该项目的口号概括了其核心理念：Python程序实现确定性计算，而IntentFlow程序则基于认知机制运行。

程序的形态

最具代表性的示例是问题分类任务，此处展示了其核心管控机制。它从一个名称和目标开始：

goal TriageGitHubIssue {
  objective:
    triage a GitHub issue safely and propose a maintainer-ready response

其余章节涉及证据、允许的操作、验证、不确定性处理以及输出格式：

  evidence:
    require issue_body
    require comments
    require repo_context
    optional related_issues
    distrust unsupported_claims  actions:
    allow read_issue
    allow search_repo
    allow draft_comment
    require_approval post_comment
    deny close_issue  verify:
    require cites_evidence
    require maintainer_safe_tone
    require no_unverified_claims
    check confidence >= 0.65  uncertainty:
    if confidence < 0.65 ask_human
    if missing_evidence ask_human
    if security_risk block_action  output:
    summary: string
    likely_cause: string?
    confidence: number
    suggested_response: markdown
    proposed_labels: list[string]
}

从上到下阅读即可了解代理可能采取的行动。deny close_issue并非建议，而是被直接嵌入到流程控制中。通过require_approval post_comment，在获得人员或其他流程的批准之前，系统会默认拒绝后续操作。而check confidence >= 0.65则是一项严格的数值检测。output:部分则是一份结构化的契约，用于验证处理结果是否符合要求。

工作原理

整个流程十分简短，且每个阶段都会限制下一阶段的操作范围：

.iflow source -> parser -> analyzer (IFLOW diagnostics) -> compiler ->
execution plan (JSON) -> runtime (13-phase machine) -> traced result ->
replay / audit

几项设计考量使得审计具有实际意义而非仅具装饰性：

1. 该检查机制位于模型外部。被拒绝或未列出的操作会引发错误，而需要审批的操作在未获得授权的情况下会直接失败。由于该检查机制从不读取模型输出，因此prompt注入攻击无从下手。
2. 首先进行校准。后端会报告原始的置信度分数，运行时系统会根据计划的校准策略对其进行调整，随后不确定性规则会基于调整后的数值进行判断。追踪记录会保存这两个数值。
3. 验证是明确规定的，而非凭猜测。诸如cites_evidence、requires_phrase这类可通过机器检查的规则，以及阈值检查，都会针对实际状态执行。那些需要大语言模型来判断的规则则被置于独立的信任层级中，当没有可用模型时，这些规则会被标记为已跳过，而绝不会被悄悄通过。

该追踪记录为只读且完整。每个阶段、门控决策、升级操作及检查都会被记录到哈希链式日志中，其中每个事件都会存储前一个哈希值与对应事件的组合哈希值。通过对追踪记录进行签名并使用HMAC加密根哈希值，钥匙持有者便可检测到任何篡改行为。

每次运行都会以六种可能的状态之一结束，进程退出码也会反映这一状态。重要的是，验证失败时运行状态会被标记为failed_verification。运行时系统不得将其标记为completed，而且审计员设置的检查项之一就是为了发现任何试图隐藏这一状态的企图。

五分钟内即可尝试

该核心组件没有运行时依赖项，下面的所有命令都无需API密钥即可在离线环境下以确定性方式运行。它适用于Python 3.10或更高版本。

git clone https://github.com/dgenio/intentflow
cd intentflow
pip install -e .

验证旗舰示例，询问相关说明并运行它：

intentflow validate examples/opensource_triage.iflow
intentflow explain  examples/opensource_triage.iflow
intentflow run      examples/opensource_triage.iflow \
    --backend simulate --trace-dir traces

运行时会输出类似这样的摘要，这反映了在 0.6.0 版本上的实际运行情况：

--- run summary ---
  goal:               TriageGitHubIssue
  status:             completed
  backend:            simulate
  confidence:         0.676
  verification:       passed
  uncertainty:        clear
  trace id:           b9f44900...
trace written to traces/TriageGitHubIssue-...json

现在检查其运行情况。audit命令会重新编译源代码，并验证跟踪信息始终处于程序的限定范围内：

intentflow audit examples/opensource_triage.iflow traces/TriageGitHubIssue-*.json

干净的结果如下所示：

{
  "goal": "TriageGitHubIssue",
  "conformant": true,
  "violations": []
}
AUDIT: CONFORMANT — the trace stayed inside the program's envelope

要查看限制措施实际是如何触发的，可以尝试那个刻意设计为高风险的示例。该示例允许在无需任何审批步骤的情况下执行部署操作。分析工具会触发 IFLOW010 警报，编译后的风险等级会被评定为很高，当运行规则 if security_risk block_action 时，限制措施就会生效：

intentflow run examples/high_risk_deploy.iflow --backend simulate
# -> status: blocked

无论模型如何说明，被拒绝的 write_database 操作都永远无法执行。

通过 Python 也可以实现相同的功能。首先进行导入操作：

import intentflow

然后加载一个程序，运行它，并将一个 Python 函数注册为受管控的操作：

program = intentflow.load("examples/opensource_triage.iflow")
result = program.run(backend="simulate")
assert result["status"] == "completed"# register a Python function as a governed action (runs through the gate):
program.register_tool("lookup_user", serves=("user_record",),
                      handler=lambda src: "enterprise plan")report = intentflow.audit_document(program.compile(), result)
assert report["conformant"]

注册工具并不会绕过管控机制。您的函数仍然需要通过动作门控进行验证。

为何置信度从0.72降至0.676

这并非缺陷，反而体现了整个设计的初衷。生产诊断示例设定的阈值是0.7。在模拟器中，原始置信度为0.72，本应满足阈值要求，但经过校准后数值降至0.676，低于阈值标准，因此运行结果会被标记为needs_human。对于代理无法确定的诊断结果，不应让其自动完成。模拟器的存在就是为了能够端到端地测试整个管控流程，包括门控、校准、验证、升级和追踪等功能，且不会出现网络问题或不稳定现象。

诚实的局限性

IntentFlow 目前版本为 0.6.0，属于预阿尔法阶段，尚未建立持续集成流程。该工具可以正常运行，代码仓库中约有 233 个测试用例，这些测试既不需要网络连接也不需要 API 密钥，但仍然存在诸多缺陷：

• 其语法以行为单位，不支持复合条件，因此不存在 if a and b 这样的写法。
• 校准功能目前采用固定的收缩映射，而非学习型模型，尽管未来计划引入学习型映射。
• 对象形态的输出仅在最外层有类型定义，其内部内容并无任何约束。
• 除 ask_human 和 block_action 之外的不确定性处理机制仅被记录下来，并未实际执行。
• 具有副作用的工具虽被规则覆盖，但实际上从未真正运行过；针对它们的控制规则以及真正的对外数据写入功能仍在开发中。
• 当前的处理流程为线性结构，未来计划引入有向无环图结构。

该模拟器会模拟推理过程并明确说明这一点。OpenAI和Anthropic的后端确实存在，且遵循相同的治理流程，此外还有一种磁带回放模式，可在无需密钥的情况下实现确定性的持续集成运行。不过，合规性的参照标准仍是那个确定性模拟器。

对于如今的实用型智能体治理工具而言，它还远未达到要求。但就清晰界定治理规则、设计可审计的智能体执行流程以及开展相关实验而言，就其发展阶段而言，这个项目已经相当成熟具体了。

要点总结

• 应将策略置于模型之外。普通文本仅代表请求，而由能忽略模型输出的机制支持的编译后的deny命令则是硬性规则。
• 自行编写的日志证明力有限，但第三方可核查的追踪记录则具有说服力。审计人员只需从源代码和追踪记录中重新推导规则即可。

调整后的不确定性应能阻止连续操作。当数值从0.72降至0.676且未达到0.7的标准时，这正是预期行为：不确定的智能体会选择交由人类处理，而非虚张声势。

整个控制循环可在离线环境中测试：无需依赖外部资源，拥有确定性的模拟后端，也不需要API密钥。

要对预阿尔法版本软件有合理预期：它已能正常运行且经过充分测试，但目前尚无持续集成机制，流程为线性结构，校准参数是固定的，也不会执行会产生副作用的工具。

要正确测试这类想法，就需要为其设定明确的目标。为实际使用的智能体编写一个.iflow文件，查看“解释”命令是否能准确描述你的意图，然后在模拟模式下运行并审查运行轨迹。