从一篇低代码旧文，重看 DeepSeek Harness、Pi 和 Keel 的 Session 设计
《不要以 DRY 之名，发明低代码 DSL 去残害你的同事》批评的不是复用本身，而是这种复用：框架把业务行为藏进配置、模型和解释器，调用处只剩一个简单入口；开发者能快速完成常见路径，遇到例外时却必须先学会框架内部那门“语言”。
这套判断放到 Agent Session 上很有解释力，但需要加一个边界：不是所有封装都是 DSL。只有当封装自己定义了数据词汇、合法状态变化，以及恢复、压缩、分支等执行规则时，它才接近一门语言。
按这个标准，DeepSeek Harness、Pi、Keel 都在设计语言。区别不在“有没有 DSL”，而在这门语言是否明确、边界是否稳定、出错时能否解释。
| import { existsSync, mkdirSync, rmSync } from "node:fs"; | |
| import { tmpdir } from "node:os"; | |
| import { join } from "node:path"; | |
| import type { AssistantMessage, Context, Message } from "@earendil-works/pi-ai/compat"; | |
| import { | |
| type FauxProviderRegistration, | |
| fauxAssistantMessage, | |
| registerFauxProvider, | |
| } from "@earendil-works/pi-ai/compat"; | |
| import { afterEach, describe, expect, it } from "vitest"; |
从最小代码讲清楚：AskUser 如何让一个 Moxt Pipeline 在完整 turn 结束后停止，以及 Pi 候选 PR 实际补了什么。
main：ab366ebe94cacd419d986be454f12b1b9913aacaacmerfight/pi#1，HEAD 0859da59earendil-works/pi#7299
一份严格区分 OpenAI 工作人员公开说明、OpenAI 官网资料、公开源码、社区测量与推断边界的中文分析。
核验日期：2026 年 7 月 30 日
公开讨论：openai/codex #36053
2026 年 7 月 29 日，个人资料标注为“Codex & ChatGPT @OpenAI”的 Tibo 公开说明：GPT-5.6 Sol 在部分 Codex 工作负载中消耗使用额度的速度高于预期。该 X 帖子属于 OpenAI 工作人员的公开说明；OpenAI 同日发布的工程文章则是官网正式资料。
在 issue #430 落地之后，Keel 的技能系统在业界处于什么位置——只讲事实，附来源，并诚实区分「已交付」与「计划中」。
本文描述的是 Keel 在公开设计（issue #430）中已承诺的技能运行时，以及 Keel 当前已交付的部分。它不声称下面每一项能力都已经合并。