proctor

Proctor MCP 服务

MCP 规范要求提供、却未实现的人工介入机制。

MCP 工具规范原文如下：

“出于信任与安全考虑，始终 应当 有人在环路中，并且能够拒绝工具调用。”

应用 应当 ……“在执行操作前向用户显示确认提示，确保有人在环路中。”

但它并未定义任何实现机制。每个客户端都在本地自行构建确认对话框，而点击之后便不会留下任何记录。发生事故后，审计人员会提出的三个问题，却都无从回答：

问题	本地对话框能显示什么
当时真的有人在场吗？	什么也不能。对话框只能证明有人点击过，不能证明那个人是谁
操作者是 Agent 的运营者以外的人吗？	什么也不能
能向不信任你的人证明这一点吗？	什么也不能

与此同时，付费 MCP 工具的发展方向显然恰恰相反。Vercel 对 x402-mcp 的宣传是 “无需账户、无需 API 密钥、无需人工介入”。对于天气 API 来说，这没问题；对于电汇来说，则完全不合适。

这个服务就是缺失的机制。

功能

一个工具：request_human_approval。

它会阻塞 Agent，等待一个并非操作者本人的真人作出决定；如果超过截止时间，则默认拒绝；并在没有管理员密钥的 Hedera 主题上返回一条引用，以便日后向第三方证明这一决定，而不必信任 Agent 或我们。

below threshold   → Proceed. Policy did not require a human (below_threshold).
above threshold   → blocks, hands a link to a phone, waits
approved          → Approved by a verified human. HCS sequence #41. You may proceed.
refused / expired → NOT approved (EXPIRE). Do not proceed.

大多数调用都不会交由真人处理。 一个会打断所有操作的监督工具，最终只会被 Agent 的所有者关闭。因此，策略会先运行，常见路径无需付费。

安装

已在 npm 上发布为 proctor-mcp，并以 io.github.louissarvin/proctor 列入 MCP Registry。

// Claude Desktop: claude_desktop_config.json
{
  "mcpServers": {
    "proctor": {
      "command": "npx",
      "args": ["-y", "proctor-mcp"],
      "env": { "PROCTOR_API": "http://localhost:3700" }
    }
  }
}

无需克隆，也无需构建。将 PROCTOR_API 指向一个 Proctor 实例；默认值为 http://localhost:3700。

无需客户端即可验证：

printf '%s\n%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | npx -y proctor-mcp

支持任何 MCP 客户端——Claude Desktop、Cursor 或你自己的客户端。传输使用通过 stdio 的 JSON-RPC 2.0，协议版本为 2025-06-18。

无需客户端即可验证：

printf '%s\n%s\n' \
  '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
  '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
  | bun src/index.ts

值得了解的三项设计决策

拒绝不属于工具错误。 返回 isError: false 和 approved: false。将拒绝标记为错误，会诱使模型把它当作暂时故障，并绕过拒绝重试，而这正是此工具要防止的行为。

无法访问不等于拒绝。 如果 Proctor 停机，工具会明确说明，并将 isError 标记为 true。“关卡不可用” 和 “真人拒绝了” 是不同的事实。将两者混为一谈，会让服务中断悄然变成拒绝，或者更糟，让系统不断重试，直到请求获批。

监督路径上没有依赖项。 通过 stdio 运行的 JSON-RPC 是一个循环，而在安全工具中添加 SDK，正是引入供应链风险的方式。只有在配置了钱包时，才会延迟导入 x402 客户端。因此，将它指向托管版 Proctor 来向真人提问时，绝不会加载 Hedera SDK。

付费模式

设置钱包后，工具便会停止模拟并开始付款：

"env": {
  "PROCTOR_API": "http://localhost:3700",
  "HEDERA_AGENT_ID": "0.0.xxxxx",
  "HEDERA_AGENT_KEY": "302e…",
  "AGENT_ALLOWED_TOKENS": "0.0.10394781"
}

随后，它会通过 Blocky402 协调器访问真实的 x402 门控并完成结算。一次已验证的运行：

[proctor] paid the gate; a witness is being dispatched from the rota
structuredContent: { "approved": false, "outcome": "EXPIRE", "paid": true }

以及 Hedera 测试网中对应的结算：

0.0.10359475   -420000     the agent pays
0.0.10349677  +415800     treasury
0.0.10349667    +4200     1% HTS custom fee, assessed on chain
fee payer 0.0.7162784     Blocky402

先执行策略，而且免费。 POST /v1/gate/evaluate 会在进行任何付款之前判断是否需要人工介入。每次调用都收费的监督工具，Agent 的所有者会在一天内将其关闭。

付费模式不会返回见证链接，这是有意为之。 门控绝不会将审批 URL 返回给付款方——如果 Agent 能访问该 URL，就能批准自己的决定，而这正是此产品所提供的独特保障。人工审核会通过运营人员的值班轮班机制触达。未付费的运营人员模式会返回链接，因为在该模式下，调用者就是运营人员。

如果没有钱包，工具会回退到 Proctor 的运营人员端点，该端点会创建真实决策，但不会进行结算，并会在自身输出中说明这一点（paid: false）。

目前尚不支持的功能

如果决策在共识完成前就已得出，证据引用可能会显示 attestation pending。记录会在之后写入，不会阻塞 Agent 的关键路径，序列号则会持久保存在决策自身的记录中。

此处仅接入了 Hedera 支付通道。门控也通过 Circle 的 Gateway 提供 Arc 支持，且 agent/ 中有相应示例；MCP 客户端仅注册了 Hedera 方案。