KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

调研与课程设计依据 — keel 龙骨

Real-world Execution 的参考信息：调研与课程设计依据

这份报告记录现实世界执行课程采用了哪些公开资料、各自解决什么问题，以及为什么以当前顺序组织内容。正文不要求先读这份报告。

调研范围

调研于 2026-08-22 完成。工程事实优先采用官方文档和一手工程文章，课程结构同时参考公开教学项目。

资料	核心内容	进入课程的部分	没有直接照搬的部分
Anthropic: Building Effective Agents	workflow、agent、工具、反馈和停止条件	从简单可组合模式开始；用环境反馈推进 Agent	文章不负责展开分布式副作用和恢复协议
Ollama Tool Calling	单工具、并行、多轮和流式工具调用	使用本地真实模型提出动作	Tool Call 之后的执行可靠性由本项目补足
Ollama Structured Outputs	JSON Schema 和 Pydantic 结构化结果	将模型输出限制为 `ActionProposal`	schema 合法不等于动作获准或执行成功
Temporal Workflow Execution	持久化 Workflow、事件历史和状态转换	Run 可恢复、状态来自历史、流程与副作用分离	不把教学项目绑定到 Temporal SDK
Temporal Activities	Activity 承载非确定性和外部副作用	把外部调用隔离在 Adapter/Activity 边界	单进程示例不模拟完整分布式 worker
AWS Builders' Library: Making retries safe with idempotent APIs	重试、副作用、client request ID、语义等价和迟到请求	幂等键必须表达稳定业务意图；同键异参要冲突	不使用云厂商特定 API
Stripe Idempotent Requests	服务端保存首次结果并比较后续参数	示例保存 fingerprint 与首次 receipt	内存实现只用于说明协议，不冒充持久化存储
Azure Compensating Transaction	最终一致性、补偿步骤、补偿顺序和失败	用 Saga 处理跨系统部分成功	不把补偿描述成数据库 rollback
Docker Seccomp	系统调用白名单式隔离和默认 profile	命令/浏览器/代码执行必须进入隔离环境	课程不在读者机器上运行真实危险命令
Playwright	浏览器自动化、上下文和可观察测试	浏览器被视为专用 Adapter，而不是任意点击工具	不把 UI 自动化细节挤进执行语义主线

公开课程样本给出的启发

样本	可借鉴之处	本课程的调整
Hugging Face Agents Course	从 Agent loop 和工具实践逐步进入框架；明确先修与练习节奏	保留真实模型动手体验，但把副作用事实、失败分类和恢复提前
DeepLearning.AI: Safe and Reliable AI via Guardrails	用连续业务场景解释输入/输出 guard；每个概念紧跟代码	两门课共享一次配置变更，避免每章更换业务背景
DeepLearning.AI: Quality and Safety for LLM Applications	从具体失败模式进入检测和监控	不把可靠执行缩减为输出质量；真实副作用使用独立状态机

资料共同指向的五个工程结论

1. 模型输出不是现实事实

模型可以提出 set_pool_limit(40)，但只有外部系统的确认或后续对账才能证明配置已经生效。聊天消息中的“已完成”不具备执行证据。

2. 重试策略由副作用语义决定

只读请求通常可以有限重试；写请求需要幂等键；结果未知时应先查询，而不是把 timeout 当成失败。课程因此把幂等放在异步与补偿之前。

3. Exactly-once 不是一个客户端开关

网络、进程和队列会产生重复投递与响应丢失。工程上通过 at-least-once 投递、幂等效果、去重记录和对账逼近业务所需语义，而不是宣称网络调用“恰好一次”。

4. 跨系统恢复依赖补偿，不依赖幻想中的全局回滚

配置系统、消息系统和设备控制通常不共享事务。补偿是一个新的业务动作，可能失败，也可能需要按不同顺序执行。

5. 安全授权和可靠执行相邻但不同

Safety Controls 决定“是否允许”；Real-world Execution 负责“获准后怎样可靠发生”。把两者混在一个 execute_tool() 中，会让策略、故障和审计都难以测试。

为什么按这个顺序学习

执行边界
  -> 动作契约
  -> 真实模型只提议
  -> 预检与 Gateway
  -> 幂等
  -> 长任务
  -> 未知结果与对账
  -> 补偿
  -> 专用适配器与隔离
  -> 审批绑定
  -> 持久化运行

这个顺序先建立稳定名词，再逐步增加时间、并发和故障。若一开始就展示浏览器自动操作或复杂工作流，读者容易把“演示成功”误认为“执行可靠”。

进入 keel 阅读