当 AI Agent 自己审批自己：MakerChecker 的职责分离治理方案

凌晨三点，你被 Slack 通知吵醒。财务系统显示一笔大额转账已完成——来自你上周刚接进来的 AI Agent。它自己创建了任务，自己执行了转账，自己标记了”已审批”。没人按下批准按钮，因为没有一个环节需要人参与。

这不是虚构的噩梦。在 AI Agent 快速渗透到业务关键流程的今天，”Agent 自己审批自己”已经从一个安全笑话变成了真实的合规风险。MakerChecker 正是为此而生——一个开源的、自托管的 AI Agent 治理层，通过结构性强制（structural enforcement）让 Agent 无法绕过人类的审批。

问题的本质：Agent 的执行链没有换手点

当前主流的 AI Agent 框架（LangChain、Claude Agent SDK、CrewAI 等）都侧重于”让 Agent 完成任务”，但很少有人问：谁来拦住 Agent 不让她做超出权限的事？

传统软件工程中的”Maker-Checker（制作-检查）”职责分离模式——一个人制作（如发起转账），另一个人检查并批准——在 Agent 的世界里完全断层了。Maker 和 Checker 变成了同一个 AI 进程的不同步骤，不存在真正的换手点。

MakerChecker 项目用一个轻量级的 Fastify + Postgres 服务，在 Agent 和它要调用的工具之间插入了三层闸门：

每一层拒绝都有明确的错误码输出，Agent 无法静默绕过。

快速部署：10 秒启动

MakerChecker 遵循”运维友好”的设计哲学，一条命令即可启动完整环境：

docker compose up

Postgres 和服务器会在 3000 端口就绪。首次启动会打印管理密钥和审批官密钥——复制它们，你会用到。

生产环境部署时，需要用 CLI 手动创建第一个管理员：

docker compose exec server node dist/cli.js bootstrap-admin \
  --email admin@example.com --name "管理员"

Kubernetes 用户还可以用项目提供的 Helm Chart 部署（非 root Pod、签名密钥挂载持久卷、预置的双角色加固）。

角色与授权：拒绝优先于放行

MakerChecker 的核心抽象是角色（Role）。每个 Agent 必须绑定到一个角色，每个角色只能调用已授权的 Skill（按版本号精确锁定）：

任何未授权的 Skill 调用在工具体执行之前就会被拒绝，返回 skill_not_granted。高风险的 Skill 需要先经过人工闸门——且发起请求的 Agent 不能审批自己的请求（enforcement.sod_violation）。

实战场景：现金对账流程

MakerChecker 内置了一个演示场景——每日现金对账（Daily Cash Reconciliation），完整展示了 maker-checker 模式的四步流程：

第一步：触发对账流程

export H='authorization: Bearer <管理密钥>'

curl -X POST localhost:3000/api/flows/daily-cash-reconciliation/runs \
  -H "$H" -H 'content-type: application/json' -d '{}'

Agent 收到指令后启动对账流程，但不会立即执行高风险步骤。

第二步：检查待审批的闸门

流程运行到需要人工签核的步骤时自动挂起：

curl localhost:3000/api/approvals -H "$H"

返回的列表显示哪些门等待批准、由谁创建、关联了什么业务数据。

第三步：人工批准

指定人员核实对账异常后执行批准：

curl -X POST localhost:3000/api/approvals//decision \
  -H "$H" -H 'content-type: application/json' \
  -d '{"decision":"approved","reason":"异常已解决"}'

注意：即使拿到了管理员 Key，发起对账的 Agent 也不能对同一运行审批——职责分离在系统层面强制。

第四步：验证审计链

每个操作都写入哈希链（SHA-256，RFC 8785 规范 JSON），上一个事件的哈希是下一个事件的 prev_hash：

docker compose exec server node dist/cli.js audit verify

docker compose exec server node dist/cli.js audit export --out bundle.json
node dist/cli.js audit verify-bundle --in bundle.json

审计包使用 Ed25519 签名，包含完整的状态机数据——可在无数据库的离线环境中验证。篡改任何一行都会导致验证失败。

两种集成方式：Flow 与 Proxy

MakerChecker 支持两种接入模式：

Flow（流程模式）：MakerChecker 负责编排整个流程的步骤和闸门，Agent 按 Step 执行。适合审批链路固定的业务流程。

Proxy Session（代理模式）：Agent 在自己的框架中运行，但每次工具调用都先过 MakerChecker 的代理检查。适合已有成熟的 Agent 框架、只想追加治理层的场景。

Python 接入示例：

from makerchecker import create_client, governed_tool

client = create_client(
    base_url="http://localhost:3000",
    api_key="mk_..."
)

session = client.proxy.open_session(label="对账处理")

match = governed_tool(
    client, session.id,
    agent="recon-preparer",
    skill_ref="txn-match@1",
    fn=match_transactions
)

result = match(statement=stmts, ledger=ledger)

同样支持 LangChain（governLangChainTool 返回 DynamicStructuredTool）和 Claude Agent SDK（governClaudeTool 返回 SdkMcpToolDefinition）。

拒绝码速查

当 Agent 尝试越权操作时，MakerChecker 返回明确的错误标识：

这些错误码可以直接写入 Agent 的异常处理逻辑，形成”拒绝→重新规划→合规后再试”的自闭环。

适用场景与注意事项

MakerChecker 目前是 1.0 版本，功能聚焦但稳定——经过单元测试和集成测试验证。当前版本没有拖拽式流程编辑器、SSO/SAML 或多租户支持；流程定义使用类型化的 JSON/YAML 文件。

适合的场景：

• 金融行业的自动化审批流（对账、转账、报表生成）
• 合规要求严格的 Agent 部署（SOC2、SOX 等）
• 需要向审计人员提供可离线验证的操作记录的团队

注意事项：

• AGPL-3.0 许可证（服务器、Web、Shared 层），SDK 和 Connector 为 Apache-2.0——可以将 SDK 嵌入闭源产品
• Docker Compose 快速启动默认使用 Postgres 管理员角色，生产环境应使用 docker-compose.hardened.yml 以非管理员角色运行（切换后审计表追加写入保护生效）
• 审计链是系统的事实记录源，定期备份 Postgres 并单独托管签名密钥

总结

在 AI Agent 大规模参与业务运营的时代，”信任但验证”已经不够了——你需要的是”绝不信任、强制执行、每步审计”。MakerChecker 用轻量级的方式在现有 Agent 框架之上叠加了职责分离与审批管控，让 AI 的高效率和人治的合规性不再互斥。

最妙的是：MakerChecker 不要求你丢弃现有框架。你的 Agent 继续跑 LangChain、Claude SDK 或者 CrewAI，MakerChecker 只是在工具调用前多了一道闸——而这一道闸，可能就是明天凌晨不被电话吵醒的关键。