KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
01. 模型说“做完了”，现实真的改变了吗？ — keel 龙骨
先看一句常见的 Agent 回复：
先看一句常见的 Agent 回复：
已将
payment-service的连接池调整为 40，并通知值班群。
这句话最多证明模型生成了一段文字。除非系统保存了配置服务的回执、资源版本和通知系统的消息 ID，否则你还不知道任何现实事实。
推理、请求和副作用是三件事
模型推理：应该把连接池改成 40
工具请求：set_pool_limit(service="payment-service", value=40)
现实副作用：配置服务提交新版本，运行实例开始采用 40
第一步发生在模型上下文中；第二步是结构化意图；第三步才改变外部系统。Tool Calling 负责把前两者连接起来，现实执行负责第三步的生命周期。
什么算现实世界执行
不只机器人和 IoT 才算“现实世界”。只要动作改变了 Agent 进程之外的可观察状态，就已经越过副作用边界。
| 动作 | 外部状态 | 典型风险 |
|---|---|---|
| 查询服务配置 | 配置未改变 | 数据越权、陈旧读取 |
| 更新连接池 | 配置版本改变 | 重复写入、错误目标、部分生效 |
| 发送值班消息 | 人收到外部信息 | 重复通知、泄密、无法撤回 |
| 写文件 | 文件系统改变 | 路径穿越、覆盖、竞态 |
| 操作浏览器 | 远端网站状态可能改变 | 错误点击、会话劫持、页面提示注入 |
| 执行命令 | 主机和网络可能改变 | 任意代码执行、权限扩大 |
| 控制设备 | 物理状态改变 | 人身与设备安全风险 |
“只调用了一个函数”不能降低风险。函数内部可能付款、发布服务或打开门锁。
控制面与执行面
生产系统通常把两类责任分开：
- 控制面理解目标、生成计划、检查权限、管理 Run；
- 执行面接收已固定的命令，调用外部系统，返回可验证回执。
flowchart LR
subgraph Control[控制面]
H[Harness] --> P[ActionProposal]
P --> V[校验与授权]
end
subgraph Execution[执行面]
G[Execution Gateway] --> A[Adapter]
A --> X[外部系统]
end
V --> G
X --> R[Receipt]
R --> H
这种分离不是为了画更多框。它让你可以单独回答：模型为什么这样建议、策略为什么允许、外部动作是否发生、失败后如何恢复。
现实系统不会只返回成功或失败
至少要保留四种结果：
succeeded 外部系统明确确认成功
failed 外部系统明确确认没有完成
pending 已受理，仍在执行
unknown 请求发出，但无法确认是否生效
unknown 最容易被错误代码吞掉。例如客户端在服务端提交成功后丢失响应，此时立即重试可能产生第二次副作用。
本章实验
把以下断言写在纸面或测试用例中：
没有外部回执，不得把 Run 标记为 succeeded。
收到 timeout，不得自动断言动作 failed。
模型声称“完成”，不得改变执行状态。
这三条是后续代码的底线。
检查理解
- Tool Call 已通过 Pydantic 校验，为什么仍不代表可以执行？
- HTTP 200 是否必然说明业务效果已经生效？
- 配置已提交但响应丢失，为什么结果应是
unknown？