OpenProse：为事件驱动的智能体工作流声明目标

Dan Barrett 介绍 OpenProse 和同事 Raymond Weitekamp、Jose Montes de Oca。他回顾提示词技巧变化很快，但人与系统沟通自己想要什么仍是一项挑战。

Barrett 说，无论模型或运行框架如何变化，人都必须表达意图。目标没有传达清楚，再强的系统也难以交付正确结果。

他把 OpenProse 描述为一种语言和框架：人可以用语言描述目标，让智能体去实现。问题随之变成应该写什么样的句子或契约。

在他的叙述中，提示技术从续写模式发展到手动组合检索结果和工具调用，再到由运行框架管理上下文。他把声明式契约视为更高一层的抽象，并非证明此前问题已经普遍解决。

Barrett 提议先写明想要的最终状态，再让运行框架选择路径。他借鉴软件工程中的组合思想：把较小的契约组合起来，使团队能够分别管理复杂性。

他倾向于写明智能体要达到什么目标，而不是规定每一步，因为不同模型可能找到不同路径。这是一种设计理念，并不保证模型一定达标或成本更低。

Weitekamp 提出两个要点：OpenProse 程序是 Markdown 文本；它们描述的工作流可以由事件驱动，而不是依靠聊天。开源方案可以在本地运行，他也演示了托管服务。

他表示，拥有既定控制措施的组织可以把文本契约与所选智能体、模型和防护机制结合使用。具体部署是否满足安全和采购要求，仍需组织自行判断。

这门语言有语法，但 Weitekamp 预计，人们更多是阅读和编辑程序，而非从零手写。智能体可以根据描述草拟可复用工作流，再由人检查和修改。

他说运行时和编译器本身也是给智能体的指令。团队将 Markdown 契约作为表达多智能体工作流的方法，同时使用底层编码智能体自身的能力。

契约可以声明子智能体、它们的技能和工具，以及输入和预期输出。团队可以指定必须使用的搜索工具或内部技能，并要求依赖不可用时停止程序。

定时任务、GitHub issue、pull request 或 webhook 都可以触发工作流。在托管服务示例中，Weitekamp 把常驻任务定义为契约加触发器，每次事件启动一次运行。

他说演示时应用支持定时任务和 webhook。处理 issue 的程序可以接收 issue 并以提交为目标；另一个程序则可以审查 pull request。

团队将独立审查与让同一会话检查自己的工作作比较。新的审查会话可以依据书面契约提供另一种视角，但审查结果本身仍需要评估。

有人问是否需要指定方法。Barrett 认为这是一条光谱：可以先写目标、开放实现方法；如果有助于重复执行或降低成本，再把成功轨迹固化成更具体的流程。

Weitekamp 把特别成功的运行称为黄金会话，可以将其转化为工作流。他指出模型行为具有非确定性，因此保留一个好例子并不保证之后得到相同结果。

他说，可见程序只是指令的一部分；更大的提示还描述类型和执行方式。目标是使用宿主运行框架的子智能体机制，而不是用专属于 OpenProse 的框架替代它。

在托管演示中，程序以 Markdown 编辑模式展示，配置放在 front matter 中。Weitekamp 说程序可以导出和分享，用户也可以让智能体起草。

他让语音智能体创建一个以持怀疑态度的资深开发者视角审查 pull request 的程序。草拟操作产生费用前，应用要求确认。

他还展示手动设置任务：选择触发器、仓库、契约和模型。对于 GitHub pull request，配置的事件到来时任务可以运行审查。

Weitekamp 介绍团队在开发产品时使用这些审查。有些修改一轮通过，有些经过多轮审查，开发智能体再根据反馈调整。

Barrett 强调每个新会话都依据声明式契约进行比较。他认为这有助于减少自我审查偏差，但独立审查仍不能证明所有缺陷都已找到。

讲者讨论用决策模型检查真实结果是否符合契约中的理想状态。他们说明，这种验证器在演讲时还是未来设想，并非已部署功能的演示。

Weitekamp 比较了 DSPy：他认为 DSPy 把模型调用隔离在结构化代码中，而 OpenProse 给智能体更多解释和执行工作流的自由。这是他对两种方法的概括。

代价是结果高度依赖模型，而且智能体可能自行宣布契约已完成。团队提出独立验证器和事件路由器作为可能的补充。

被问及强化学习时，Barrett 说文本契约可以版本管理和分享，也可能支持训练。讲者表示当时正在讨论这一方向，而非已经实施。

持怀疑态度的审查程序草稿完成。由于之后每个 pull request 都可能触发付费运行，Weitekamp 确认部署，然后展示应用中的常驻任务。

Barrett 转向本地部署场景。他说企业可以把开源应用层与自己的运行框架及获批模型结合；是否完全留在内部取决于实际基础设施和模型选择。

团队把操作流程视为组织知识，也视为指令。对于不希望把敏感数据或做法发送给外部提供商的组织，在内部保留工作流和模型处理可能很重要。

金融示例是量化模型文档。Barrett 说文档可能需要定期或在特定事件后更新，内容包括用途、测试条件、依赖关系及其他合规要求。

他认为这项工作需要投入大量专家时间。由于许多要求以文字写成，团队把它们表达为契约，再通过编码智能体生成草稿。

在演示中，他在 Codex 启动程序，并展示指导智能体查找和理解指令的 Markdown 内核。另一份程序则规定所需文档和条件。

示例使用公开的 SOFR 曲线，而不是银行内部数据。生成的文档显示在屏幕上，但工作坊并未证明草稿已可投入生产或提交监管机构。

Barrett 表示团队会把输出与历史工作、耗时及专家评分比较。他也承认，合规团队、审计人员和监管机构的批准是流程中的另一部分。

一位参与者问人们如何创建契约。Barrett 说智能体可以依据项目指南和反模式协助迭代，但把人的真实意图表达出来仍然困难。

Weitekamp 说，当人还不知道自己想要什么时，聊天可能很有用。任务逐渐明确后，可复用契约才更适合；助手可以帮助制定契约。

Barrett 说，他们面向的是重视可靠性、可重复性和可审计性的重复任务；对于探索性或一次性工作，他建议使用普通聊天。

多个契约可以组合，使一次运行满足多项要求。Barrett 还介绍上游依赖：输入变化时，下游工作可能需要更新。

团队正在探索用决策模型充当语义分类器，检测状态变化并判断是否重新运行下游工作。Barrett 明确表示，这项集成当时仍在开发中。

Weitekamp 以写文章为例：研究员使用指定搜索工具，作者参考示例，编辑检查草稿，由主智能体判断结果是否达到目标。

Barrett 解释，中间契约可以充当检查点。每个阶段满足自己的条件后才进入下一阶段，同时智能体仍可灵活选择满足条件的方法。

Weitekamp 列出并行分发与汇总、对抗式审查，以及带退出条件的循环等工作流形态。团队说，这些模式依赖底层智能体能力；许多复杂场景还需要隔离的子智能体。

被问及框架的依据时，Barrett 提到工程经验和内部实证测试。他说团队用测试检查缩短后的内核是否仍符合预期行为。

Weitekamp 介绍把现有技能组合成分阶段工作流，例如先提问，再使用测试驱动开发流程。讲者表示希望测试具体的规格驱动工作流，而不是声称所有组合都已经可用。

Barrett 最后说，用户不仅把 OpenProse 用于软件开发，也用于运营、产品管理和量化模型文档。共同需求是以可重复的方式表达并执行工作。