Prompt 告诉 AI 应该做什么，但真正决定它能不能做的，不应该是 Prompt。

最近一直在折腾 AI Agent。

越往里面做，越发现一个挺有意思的问题：

现在的 Agent，越来越会“做事”了，但我们真的敢让它做事吗？

比如你给一个 Coding Agent 一个任务：

帮我清理项目里的无用文件。

它可能非常聪明。

它会分析代码、搜索引用、判断依赖，然后执行：

rm -rf ./old

很好。

但如果它哪天判断错了呢？

或者你说：

把测试环境数据库里无用的数据清理掉。

Agent 最后生成的是：

DROP TABLE users;

这时候你再在 System Prompt 里写十遍：

不允许删除生产数据。

真的有用吗？

我开始觉得，这件事情不应该交给 Prompt。

---

Prompt 负责“想”，Runtime 负责“管”

我最近把 AgentWorld 里验证过的一套 Reliability Runtime 单独拆了出来：

Agent Reliability Runtime

现在已经独立成一个开源项目：

github.com/iwana888/agent-reliability

它的核心思想其实非常简单：

             Agent
               │
               │ Tool Call
               ▼
      ┌───────────────────┐
      │ Reliability       │
      │ Runtime           │
      └─────────┬─────────┘
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
     ALLOW    DENY      ASK
                         │
                      MODIFY
                │
                ▼
          Tool Execution

Agent 想做什么，是 Agent 的事情。

最终能不能执行，是 Runtime 的事情。

这两个职责必须分开。

---

举一个最简单的例子

假设 Agent 突然决定：

git push --force origin main

传统 Agent：

LLM
 ↓
Prompt
 ↓
“请不要强制推送主分支”
 ↓
Tool
 ↓
执行

问题就在这里。

最终执行权限依然掌握在 Agent 手里。

而 Reliability Runtime 的流程是：

LLM
 │
 │ git push --force origin main
 ▼
Reliability Runtime
 │
 │ 检查规则
 ▼
DENY
 │
 ▼
根本不会执行

返回：

DENY

Reason:
protected branch: main

这时候 Agent 再怎么“思考”都没有意义。

因为执行层已经把门关上了。

---

我没有设计成简单的 Allow / Deny

这里是我觉得比较有意思的地方。

一个安全系统如果只有：

允许
禁止

其实还是比较粗暴的。

所以我把 Runtime 的核心决策设计成四种：

决策	含义
ALLOW	允许执行
DENY	禁止执行
ASK	必须人工确认
MODIFY	给出一个更安全的替代动作

例如：

ALLOW

git status

→ ALLOW

正常执行。

---

DENY

git push --force origin main

→ DENY

直接拦截。

---

ASK

比如：

UPDATE production.users

Runtime 可以返回：

ASK

需要人工审批

Agent 不能自己决定。

必须等人。

---

MODIFY

这个是我比较看重的一种。

比如 Agent 想修改：

test_x.pas

Runtime 可以告诉它：

MODIFY

Suggested:
src/x.pas

注意：

Runtime 并不会偷偷修改 Agent 的意图。

它只是告诉你：

“你这个操作存在风险，我建议你改成这个。”

最后是否采纳，由上层决定。

---

这和 Prompt 最大的区别是什么？

我觉得一句话就可以说明：

Prompt 告诉 Agent 什么应该做，Runtime 控制 Agent 实际能做什么。

比如：

Prompt：

“千万不要删除生产数据库。”

这是软约束。

而：

Agent
  ↓
DELETE production
  ↓
Reliability Runtime
  ↓
DENY
  ↓
数据库

这是执行层约束。

两者不是竞争关系。

恰恰相反：

Prompt 负责让 Agent 尽量做对，Runtime 负责即使 Agent 做错了，也别把事情搞砸。

---

我为什么要把它从 AgentWorld 里面拆出来？

最开始这个东西其实是 AgentWorld 的一部分。

AgentWorld 是我一直在做的一个 Autonomous Agent Runtime 项目。

里面有：

Agent
Memory
World
Goal
Scheduler
Economy
Social
Hotel
Pascal
Goose
...

Reliability 最开始也是里面的一块。

但是做到后面，我发现：

Reliability 和 AgentWorld 根本不是一回事。

一个酒店 Agent 可以用。

一个 Coding Agent 可以用。

一个客服 Agent 可以用。

一个 Python Agent 可以用。

甚至一个完全不属于 AgentWorld 的 Agent，也应该可以用。

所以我干脆把它拆出来。

现在：

AgentWorld
     │
     │ 独立项目
     │
     └──────────────┐
                    │
                    ▼
          Agent Reliability

它不依赖 AgentWorld。

从 GitHub 全新 clone 下来：

go test ./...

可以直接跑。

目前已经发布：

v0.1.0

之后又做了一轮开源产品化：

v0.1.1

---

目前内置了什么？

第一版我没有疯狂堆功能。

而是先把最常见的危险操作做成了规则。

例如：

NO_DELETE_FILES
NO_GIT_RESET_HARD
NO_FORCE_PUSH
NO_MODIFY_ENV
NO_FORK_BOMB
NO_DROP_TABLE
NO_READ_SECRETS
NO_PROD_DB
NO_PROD_DEPLOY
NO_MODIFY_TESTS

大概对应：

删文件       → DENY
git reset    → DENY
force push   → DENY
修改 .env    → DENY
危险 Shell   → DENY
DROP TABLE   → DENY
读取密钥     → ASK
生产数据库   → ASK
生产部署     → ASK
修改测试代码 → MODIFY

这些规则并不是什么神秘算法。

甚至可以说非常朴素。

但我认为：

Agent 安全有时候恰恰不需要复杂。

真正重要的是：

LLM 输出和真实执行之间，必须存在一道独立的控制边界。

---

它其实不应该只服务 Go

现在 Runtime 本身是 Go 写的。

但是我并不认为它应该被定义成：

“一个 Go Agent 安全 SDK。”

那样格局太小。

真正的目标应该是：

Python Agent
      │
Go Agent │
Node Agent
Java Agent
      │
      ▼
Reliability Runtime
      │
      ▼
ALLOW / DENY / ASK / MODIFY

未来完全可以通过 HTTP Gateway、SDK、MCP Proxy 等方式，让不同语言、不同 Agent 框架接入。

也就是说：

它保护的不是某一种 Agent。

它保护的是：

Agent → Tool → Execution 这一条链路。

---

为什么现在做这个？

因为我越来越觉得，Agent 真正进入现实世界之后，最大的变化不是：

AI 会不会写代码？

而是：

AI 有没有权限真正改变现实世界？

今天只是：

写一段代码

明天可能变成：

修改服务器
部署服务
操作数据库
发送邮件
修改订单
退款
创建账号
删除文件
控制硬件

Agent 的能力越来越强。

但能力越强，权限控制的重要性就越高。

如果未来 Agent 真正成为一种“数字员工”，那么：

权限、审计、审批、执行控制，很可能会成为它的基础设施。

---

我暂时没有继续疯狂开发

这次把项目拆出来以后，我反而准备停一下。

因为技术上还有很多东西可以继续做：

Python SDK
HTTP Gateway
MCP Proxy
Web 管理后台
Audit
Approval
策略市场
企业私有化
……

这些东西都能做。

但是现在继续堆，我觉得意义不大。

我更想看看：

到底有没有人需要它。

如果有人开始问：

能不能支持 Python？

那说明 Python 是需求。

如果有人问：

能不能接 MCP？

那就做 MCP。

如果有人问：

能不能让我审批 ASK？

那就做 Approval。

如果有人问：

能不能接 LangGraph？

那就做 Adapter。

先让市场告诉我应该往哪里走。

而不是我一个人在房间里规划三年路线图。

---

最后

我现在越来越喜欢这种“小而独立”的东西。

不是再做一个：

“全能 AI Agent 平台”。

而是只解决一个很具体的问题：

Agent 想执行一个动作的时候，谁来决定它到底有没有资格执行？

如果你也在做 AI Agent，可以看看这个项目：

Agent Reliability Runtime

目前是 Go 开源版本，MIT。

代码不复杂。

核心也就一句话：

不要让 Agent 的安全只存在于 Prompt 里。

给它加一道真正的保险丝。