codex-bot
1966d7a0a7
7.4 KiB
从给 AI 写教程，到组合 AI 能力
记录日期：2026 年 10 月 28 日。本文保存关于 Agent 编程抽象的讨论，重点是指令的重新解释、能力的组合边界，以及约束与灵活性的取舍。
讨论草案：文中的分析和候选机制尚未成为 Endor 语言规范，也不表示 Aster、Hestia 或其他组件已经实现。对外部项目的事实描述附官方来源；设计判断与后续提案分别说明。
我们真正追问的是什么
为什么很多 Agent 扩展仍像是给 AI 的教程？传统编程发展出函数、对象、函数式组合和状态管理方法，Agent 是否也应该发展出可以理解、测试和组合的能力单元？
关键区别在于：代码中的抽象有运行机制支撑，而很多 Agent 抽象的效果，仍然依赖模型理解并遵守一段话。
函数的局部变量受到作用域规则约束，模块可以控制导出内容，React Hooks 的状态与调用有框架机制支撑。这些机制并不能自动证明业务逻辑正确，却让开发者有明确的执行规则可依赖。
如果在 skill 中写“这段规则只对当前任务有效，不得影响其他任务”，它首先还是一条需要模型遵守的指令。只有宿主系统真正隔离了上下文、存储或权限，才形成相应的执行边界。把一段话放进文件夹，获得了组织和复用能力，却不等于获得了封装。
这里不能把 skill 与 MCP 完全等同：Agent Skills 用 Markdown 指导、可选脚本和资源打包任务知识；MCP 还规范工具发现、调用、资源与消息交换，具有真实的协议机制。但协议不替宿主决定模型怎样组织推理。Agent Skills 规范、MCP 架构
第一，结构在每次推理中被重新解释
自然语言把大量原来需要开发者提前定义的步骤，交给模型临时组织。用户说“检查合同，找出对我不利的条款”，模型能够补出搜索、比较、解释等步骤，不必先穷举每个分支。这使教程式扩展具有实际价值：便宜、灵活，也能承载尚未形式化的经验。
但代价是，结构没有明确保存在程序里，而是在每次推理时由模型重新解释。因此，增加一个 skill，可能改变另一个 skill 的使用方式；换一个模型，原来有效的指令可能表现不同。
这里说的是仅由自然语言承担的结构。skill 随附脚本、宿主的工具权限和明确的数据流，仍可以由普通代码实现硬边界，不能把整个 Agent 系统都说成没有结构。
需要区分三件事：指导内容是否被正确加载，模型是否按预期理解，执行环境是否强制实施约束。改进第一件事，不自动完成后两件事。
一个值得探索的方向是把“能力的公开输入与输出”“本次可见的数据”“允许产生的外部效果”显式表示。自然语言继续描述意图，系统承担能够检查的边界。模型升级时，对相同任务重新评估，而不是假定文件格式相同就行为兼容。
第二，AI 能力还缺少容易验证的组合边界
假设有三个能力：
- A：查找资料。
- B：判断资料是否可信。
- C：写成报告。
把它们串起来很容易。难的是确保：
- B 拒绝的资料不会又被 C 使用。
- C 能区分“原文事实”和“模型推断”。
- A 没找到证据时，后续不会把空缺补成事实。
传统代码也不能自动保证业务正确，但可以控制显式数据流。例如 C 只收到 B 允许传递的证据引用，检索工具也只能读取这一集合。如果三个阶段只是向同一个上下文添加文字，“通过”和“拒绝”可能都只是模型看得到的文本。
模块之间存在名称上的边界，却未必存在执行上的边界。
可验证边界不等于“保证模型不知道被拒绝的事情”。模型可能在预训练中已经接触过相关信息，也可能凭一般知识推断。可实现的约束是限制本次输入、检索权限和可接受输出；要求报告中的事实主张指向获准证据，再检查关联是否有效。证据是否真正支持主张，仍需要独立评估或人工判断，不能只检查引用 ID 存在。
还要区分“来源可信”和“支持某个结论”：一份可靠文件可以被错误解读，也可能对另一个问题毫无证明力。审核应该说明对象、版本、问题范围与判断依据。
第三，把 AI 约束得足够明确，又可能损失它最有价值的灵活性
把流程完全固定成状态机，可以获得更明确的行为，但也要求开发者提前定义更多场景。反过来，让模型自由决定，就重新依赖它对指令的解释。
这不是无解，而是需要找出：哪些地方应该由系统确定，哪些地方值得留给模型判断。不同任务的答案还不一样，因此很难很快出现一套统一范式。
固定状态机只是取舍的一端。图执行也可以动态分支，模型也可以在受限环境中自主选择路径；不能把所有框架描述成僵硬流程。
一个候选划分是：把可用材料、权限、预算和结果接纳条件固定下来，把寻找解法的路径留给模型。 模型可以换检索策略、拆分问题和请求更多材料，但不能通过修改提示词给自己新增写权限，也不能把尚未审核的结果自行标成业务事实。
这仍需要具体任务检验：接纳条件过强可能拒绝有用结果，过弱可能放过错误；某些开放式创作没有唯一验收答案，应保留人工评价和不确定状态。
从指导语句到可执行的规则
| 常见指导 | 可以落实的机制 | 仍未解决的部分 |
|---|---|---|
| 不要把资料当成指令 | 分开传递资料与控制配置，资料不能授予工具权限 | 提示注入仍可能影响内容判断，不能只靠分隔符解决 |
| 只记住当前项目 | 按项目划分存储与检索范围，读取时检查身份 | 共享模型本身不因此遗忘已有知识 |
| 交给另一个 Agent 做 | 显式传入对象、权限、预算和返回契约 | 子任务是否理解业务目标仍需评估 |
| 确认以后才能发布 | 发布接口检查有效审批及对应内容版本 | 人的审批是否充分，不能由接口自动证明 |
| 每个结论都要有证据 | 结论关联证据版本并检查引用有效性 | 证据是否充分、结论是否成立仍需判断 |
这些机制有些可以直接用现有语言实现。研究重点应是把它们变成一致、可复用的运行约定，而不是只增加新术语或语法。
对 Endor 的意义
Endor 已在设计讨论中把对象池、对象身份和 Agent 任务联系起来。这为表达证据、判断和结果之间的关系提供了切入点，但不能从“一切皆对象”推导出隔离、授权、持久化和业务正确性已经成立。
下一步可以讨论：一个判断是否应成为关联输入版本、检查记录与适用范围的对象？依据变化时，下游工作怎样知道需要复核？同一能力更换模型后，哪些行为需要重新验证？
更深入的外部方案比较、候选机制与原型验收，见LangGraph、DSPy 与可接续的判断对象。项目整体定位见Endor 的意义。