KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Real-world Execution — keel 龙骨
值班人员要求 Agent 把 payment-service 在 staging 环境的数据库连接池从 20 调到 40，然后通知值班群。模型很快给出了两个动作：修改配置、发送通知。
值班人员要求 Agent 把 payment-service 在 staging 环境的数据库连接池从 20 调到 40，然后通知值班群。模型很快给出了两个动作：修改配置、发送通知。
章节目录
- 01. 模型说“做完了”，现实真的改变了吗？ — 先看一句常见的 Agent 回复：
- 02. 一个动作需要哪些不会含糊的字段？ — 如果整个执行链只传递这段数据，出了问题几乎无法恢复：
- 03. 让 Ollama 只负责提出动作 — 现在接入真实模型，但只交给它适合语义判断的部分：从用户目标和当前状态中提出候选动作。模型不会直接访问配置 API，也不会生成可信权限字段。
- 04. 执行前，先让变化变得可见 — 直接把 Command 交给外部 API，会错过最后一次低成本发现问题的机会。Execution Gateway 在动作目录、预检、幂等存储和领域 Adapter 之间建立统一边界。
- 05. 重试为什么可能把一次事故变成两次？ — 配置服务已提交 pool_limit=40，但响应在网络中丢失。客户端看到 timeout，于是再次发送请求。如果第二次请求被当作新意图，审计记录、配置版本和下游事件都会重复。
- 06. 一个动作五分钟后才完成怎么办？ — 发布、批量导入、视频处理和设备校准无法在一次短 HTTP 请求中完成。外部系统通常先返回“已受理”，再通过轮询、回调或事件报告最终状态。
- 07. 超时以后，最重要的是承认“不知道” — 客户端调用配置服务，等待 10 秒后超时。以下三种事实都会产生同一个客户端现象：
- 08. 不能回滚的世界，怎样收拾部分成功？ — 一次变更包含两个步骤：
- 09. 浏览器、文件、命令和设备不是普通函数 — 统一的 Action 协议不意味着所有动作共享同一种执行环境。HTTP API、浏览器、文件、Shell 和物理设备需要不同 Adapter，也需要不同隔离与恢复策略。
- 10. 人工批准的必须是将要执行的那个动作 — 值班人员看到 preview：“把 staging 连接池从 20 改到 40”，于是点击批准。执行前模型重新规划，把参数改成 80。如果系统只保存 approved=true，80 也可能借用旧批准被提交。
- 11. 进程重启后，Run 如何接着走？ — 如果执行状态只保存在 Python 变量里，进程在“外部提交成功、保存本地回执之前”崩溃，重启后就无法判断下一步。持久化执行的目标不是让进程永不失败，而是让失败后仍能根据历史恢复。
- 12. 完成一次可恢复的配置变更 — 结课项目把同一个业务意图拆成两步：更新 payment-service/staging 的连接池，再发送值班通知。目标不是让一次演示顺利跑完，而是让每一种中断都有明确状态和恢复动作。