核心哲学：从“怎么做”转向“做什么”

Dan Barrett作为OpenProse的创始人，回顾了自2021年4月被Eleuther AI社区评为“最佳提示词工程师”以来的五年变迁。他指出，尽管大模型技术日新月异，但核心挑战始终未变：如何将人类意图准确传达给超级智能。早期的提示词技巧（Prompting）已逐渐被更高级的抽象层取代，当前的重点不再是教模型“如何”执行任务，而是定义期望的结果、目标或最终状态。这种思维转变被称为“声明式”（Declarative）编程，即告诉系统想要什么，而非规定其执行路径。Dan强调，如果由人类详细指定步骤，实际上是在浪费模型的智能并增加成本；相反，应利用模型自身的推理能力来自主决定实现路径。这种理念借鉴了传统软件工程中的“组合优于继承”原则，旨在通过声明式契约（Contract Creation）来管理复杂性，使系统各部分能够优雅地组合。

OpenProse的技术定位与架构特征

Raymond Weitekamp进一步阐述了OpenProse的具体技术形态，将其定义为基于Markdown的文本驱动框架。他提出了两个关键记忆点：首先，OpenProse本质上是一个由纯文本构成的大提示词（One Giant Prompt），而非传统的代码库；其次，它是事件驱动的（Event-Driven）多智能体工作流系统，而非简单的聊天交互。Raymond指出，虽然可以通过自然语言与Agent对话来生成OpenProse程序，但其核心运作机制是事件驱动的多智能体协作。该框架支持本地运行（通过NPX）及托管服务，旨在让非技术人员也能构建复杂的AI系统。这种架构设计使得用户无需深入理解底层模型细节，只需关注事件流与状态定义，即可实现复杂的自动化任务编排。

团队背景与传统工程经验的迁移

OpenProse团队的构成体现了传统软件工程经验与前沿AI技术的深度融合。Dan Barrett拥有12年软件开发背景，Jose Montes de Oca曾就职于Google Cloud早期团队，而Raymond则是拥有博士学位、两次创业经历的资深工程师。这种背景使得他们能够将经典软件工程模式应用于新兴的AI领域。Raymond特别提到，尽管外界常称其为“氛围编程”（Vibe Coding）专家，但其核心竞争力在于对Harness工程（编排引擎工程）的深刻理解。团队致力于解决的一个关键问题是：当上下文工程和Harness本身已经自动化时，如何定义“命名所需之物”的最佳实践。他们主张通过声明式契约来解耦意图与实现，从而让Harness能够自我调整拓扑结构、分发子智能体并执行循环操作。这种设计不仅提高了系统的可维护性，还允许在不同复杂度需求的场景下灵活选择模型——简单任务可由低成本模型处理复杂逻辑由智能更强的模型自主规划。

面向受监管行业的无部署优势

对于银行等小型受监管行业而言，OpenProse 的核心吸引力在于其全文本驱动的特性。这意味着企业无需依赖采购部门或 IT 部门的介入，也无需部署复杂的底层基础设施。用户可以使用任何代码代理、推理引擎或现有的护栏（guardrails）及技术栈，只需通过Markdown 文件即可创建多代理工作流。这种架构极大地降低了合规审查的门槛，因为交付物仅是文本文件而非二进制程序或封闭系统。对于非技术人员来说，只要能够阅读逻辑英语（logical English），就能理解 OpenProse。虽然它在技术上是一种具有语法的编程语言，但其设计初衷并非让用户从头手写代码或学习复杂的模式（schema），而是由人阅读和编辑。用户只需描述工作需求，让代理生成 Prose 程序，再根据生成的结果进行人工调整，最终形成可复用的工作流。

开发者视角的“提示即编译器”架构

对于 AI 工程师和开发人员，OpenProse 提供了一种独特的开发范式：它既是一个框架，又不是一个传统意义上的框架。其核心机制在于编译器本身就是巨大的提示词（prompt）。正如演讲者所言："> You are the compiler. This is not an analogy." 这种设计允许开发者利用代码生成模型（如 Codex）来编译程序，实现了将代码植入到编译器中。开发者可以通过简单的 Markdown 契约表达极其复杂的多代理工作流，其复杂度堪比 Anthropic 的动态代理工作流程。在 OpenProse 中，程序的核心是目标（goal）与维护契约的定义。开发者可以使用 prose write 函数声明程序，指定子代理及其特定技能。例如，如果开发者偏好使用 Exa 搜索引擎而非普通网络搜索，可以在契约中明确指定该技能及其 CLI。如果依赖项缺失，程序将拒绝编译。这种机制确保了工作流的健壮性，输入和输出由契约严格定义。

事件驱动的工作流与 GitHub 集成案例

OpenProse 旨在摆脱传统的“对话式”或“聊天式”工作流，转向事件驱动系统（event-driven systems）。在这种模式下，任何触发器——如定时任务、GitHub 新 Issue、Pull Request（PR）或 Webhook ——都可以启动端到端的工作流。在 run.prose.md 平台中，工作（Job）被定义为契约加触发器。目前主要支持的触发器包括 Webhook 和 Cron Job。演讲者展示了一个具体的 GitHub Issue 处理案例：当新 Issue 产生时，系统自动编写一个 Prose 程序来处理该问题。这个工作流可以是简单的也可以是复杂的多代理协作，其输入是 Issue 内容，输出是一个 Commit。此外，还展示了针对 PR Review 的事件驱动对抗性审查机制。这种架构允许企业构建“代码工厂”，通过预设的站立工作流自动响应外部事件，确保从触发到交付契约的全过程自动化。

解决自我审查偏差与引入反向压力机制

在 Anthropic 的研讨会中，演讲者指出了 AI Agent（如 Claude Code）在执行自我审查时面临的固有挑战。当用户让 Agent 将代码推送到生产环境并要求其再次检查时，Agent 往往存在确认偏误（Confirmation Bias），倾向于认为自己已经做得很好。这种心理偏差与人类相似，导致自我审查的有效性降低。为了解决这一问题，OpenProse 引入了一种通过 Pull Request（PR）机制从应用程序本身获取“反向压力”的工作流。 这种设计不依赖 Agent 的自觉，而是通过外部流程强制进行代码审查和质量控制。与此同时，演讲现场还穿插了关于硬件设备（手与手机）的轻松互动，展示了技术演示中的人情味。这种将流程控制外置而非完全依赖 Agent 内部逻辑的思路，是提升系统可靠性的关键一步。

“What”与“How”的动态平衡策略**

OpenProse 的核心理念在于区分“声明结果（What）”与“指定过程（How）”。在初始阶段，用户应尽可能宽松地声明期望的结果，让智能 Agent 自行探索实现路径。随着工作流的成熟，用户可以利用“固定 How（Pin the How）”功能语法，将 Agent 的最佳执行轨迹固化下来。这一过程被称为“收缩包装”，即将原本开放的探索转化为确定性的程序化指令。这种从完全声明式向过程式指令的转变，能够显著降低后续执行的成本。因为初始探索可以使用昂贵的大模型来寻找最优解，而固化后的流程则可以通过更轻量、更确定的指令重复执行。这种动态调整策略使得用户可以在灵活性与成本控制之间找到最佳平衡点，避免了每次运行都消耗高昂的计算资源。**

应对非确定性：从“黄金会话”到可复用工作流**

针对 AI Agent 输出非确定性的问题，团队提出了将“黄金会话（Golden Session）”转化为可复用工作流的方案。用户可以将一次完美的交互记录保存下来，使其成为标准化的操作流程。然而，演讲者指出，单纯固化流程面临两个挑战：一是随着各大公司算力受限，原本稳定的端点可能会发生变化；二是用户期望值的“温水煮青蛙”效应——初次惊艳后，重复使用时的满意度会下降。 因此，仅仅复制 Markdown 文件是不够的。OpenProse 的底层系统提示词（System Prompt）或技能定义实际上非常庞大，曾达到接近 70,000 到 80,000 tokens，并包含复杂的类型系统来覆盖 Markdown 的局限性。随着 Agent 能力的提升，团队正在努力精简这些提示词。这种对底层复杂性的管理，确保了即使在 Markdown 表面之下，系统也能维持高度的结构化和可靠性。

解耦框架与自定义执行环境**

OpenProse 强调其作为“元编排层（Meta Harness）”的角色，而非直接替代具体的执行框架。演讲者明确表示：“我们不想成为那个 Harness（编排器），我们希望被 Harness 编译。” 这意味着 OpenProse 不干预底层 Agent（如 Claude Code 或 Codex）特有的子代理系统，以保持与不同模型的兼容性。例如，Claude Code 有其特定的子代理机制，而 Codex 则完全不同。通过保持这一层的中立性，OpenProse 允许用户“自带 Harness（Bring Your Own Harness）”，从而适应多样化的技术栈。在演示环节，用户通过自然语言指令让 Agent 生成一个 Review PR 的 Prose 程序。Agent 在确认操作涉及费用后，自动生成了包含所有连接逻辑的完整代码。这一过程展示了从自然语言意图到可执行、跨平台工作流的无缝转换，体现了其“纯 Markdown”但功能强大的设计理念。

基于 Cron 和 Webhook 的自动化任务调度机制

在 OpenProse 平台中，任务的触发方式非常灵活。除了传统的定时任务（Cron Job）外，系统还提供了开放的 Webhook 接口，允许开发者自定义触发逻辑。用户可以选择使用平台特定的 Webhook，或者将 OpenProse 接入自己的服务监听外部事件。以 GitHub Pull Requests（PR）为例，平台提供了简化的集成方式。开发者只需在 run.pros 文件中配置即可实现自动化流程，例如预先编写好“审查代码”的契约（Contract），并指定使用的模型。目前平台支持 OpenAI 排名前三的主流模型，未来还会扩展更多选择。这种配置方式使得开发者能够轻松地将代码审查任务自动化，无需手动干预即可启动复杂的 Agent 工作流。

利用审查反馈作为系统背压（Back Pressure）的实战案例

在实际操作中，Dan Barrett 展示了如何利用审查过程产生的反馈来优化系统稳定性。他提到，在短短几天内，平台处理了 数十次 PR 审查请求。这些任务并非一次性完成，而是根据 Agent 的表现进行多轮迭代。有些简单的审查只需一轮即可通过，而复杂的案例则可能经历多达 14 轮 的反复审查，直到 Agent 的输出与契约要求完全对齐。这种机制实际上构成了系统的“背压”：如果审查未通过，任务不会结束，直到开发者 Agent 根据反馈修正代码。Dan 分享了一个具体案例：他在演示前发现生产环境与测试环境的审查结果不一致，于是指示 Agent 在预发环境（Staging Server）上模拟触发条件，但要求 Agent 必须使用系统自身的反馈机制 来调整行为。最终，两个环境的审查结果趋于一致。这种基于契约的对比验证模式 确保了 Agent 不会陷入自我确认的死循环，而是通过外部标准进行校准。

“契约验证”模式与决策模型（如 Jeff）的结合前景

三位演讲者深入探讨了 OpenProse 的核心优势：所有 Agent 的输出都需与声明式编写的 契约（Contract） 进行对比验证。这种模式将模型从“自我置信”的循环中解放出来，通过生成新的会话并对照契约进行基准测试。Raymond Weitekamp 指出：

"All of these are getting compared against a contract... spawning new sessions and bouncing them off of a contract, which is I just a better pattern for how to do it."

关于是否可以使用一次性分类器（如 Jeff）来加速这一过程，团队认为虽然 OpenProse 本身是生成式语言模型（LLM），不适合直接替代 Jeff，但 决策模型可以作为后端验证器 发挥作用。OpenProse 的弱点在于它依赖 Agent “自我声明”已完成，不同模型可能给出差异巨大的结果。因此，引入类似 Jeff 的 System One 快速决策模型 作为最终验证步骤，既便宜又高效。此外，团队还计划构建 路由器（Router） 功能，让系统自动识别 GitHub 事件类型并分发到相应的审查任务中，进一步减少人工配置。

文本作为强化学习（RL）的理想载体

最后，讨论转向了 OpenProse 与 强化学习（Reinforcement Learning, RL） 的结合潜力。Dan Barrett 提到，Twitter 上关于“为何不对此进行 RL”的讨论非常热烈。他认为，OpenProse 使用 Markdown/文本作为语言形式，这使其成为 RL 的完美载体。因为代码和契约都可以被版本控制（如 Git），团队成员可以在 Notion 或 Jira 中协作编写和审查这些文本。从工程角度来看，纯文本结构使得奖励函数（Reward Function）的设计变得清晰且可行。虽然目前平台尚未完全实现 RL 训练，但团队明确表示这是未来的重要方向。通过让 Agent 在契约约束下进行自我优化和强化学习，OpenProse 有望实现更智能、更稳定的自动化工作流。

文本化数据对强化学习与Token效率的优化价值

在讨论如何将组织内的非结构化信息转化为Agent可用的资产时，演讲者指出将一切内容写为纯文本形式对于强化学习（RL）具有显著优势。虽然目前OpenProse尚未达到需要极致优化的数据量级，但对于自托管模型且面临长上下文（如10万Token前缀）的场景而言，构建更高效的Token表示形式至关重要。这种优化不仅提升了处理速度，还降低了计算成本。

"Yeah, we haven't hit volumes where this is important... if you are hosting the model and you have this 100,000-ish token prefix... build these um more token efficient representations."

演讲者强调，如果用户希望在OpenProse中处理万亿级Token（trillion tokens）的数据量，平台将乐意提供相应的技术支持。这种对文本化数据的高效处理能力，为后续构建复杂的自动化工作流奠定了底层基础。

基于事件的PR审查自动化与部署流程演示

为了展示OpenProse在实际工作流中的应用，演讲者演示了一个“愤世嫉俗的高级PR审查员”（Grumpy Senior PR Review）的自动化案例。该系统的核心逻辑是：当新的Pull Request（PR）产生时，自动触发一个Job并开始消耗计算资源。用户只需点击确认部署，系统便会启动审查任务。

在演示中，演讲者展示了Job列表界面，其中“Grumpy AI skeptic PR review”任务位于顶部或底部。他幽默地表示，自己负责维护run.pros.md文件，如果用户遇到任何问题，“不要告诉我的老板”，直接联系他即可。这一案例突出了OpenProse作为基于事件系统（event-based systems）的易用性，用户无需深入了解底层架构即可快速部署自动化审查流程。

企业级本地化部署与机构知识保护策略

针对大型企业对数据安全的顾虑，演讲者明确指出OpenProse并非必须依赖云端服务。用户可以选择本地部署（on-prem），结合自有的开源模型和“自带Harness”策略，构建完全内部化的全栈解决方案。这种架构允许企业将OpenProse作为应用层（application layer），叠加在自有模型之上。

"More important than your data, you don't want to be shipping your standard operating procedure out to the big labs."

演讲者强调，机构的操作知识（Institutional Operational Knowledge）比数据本身更敏感。OpenProse本质上是将标准操作程序（SOP）文档化，因此企业不应将这些核心流程暴露给大型模型实验室。OpenProse采用开源核心（open core）模式，拥有许可协议，允许大公司将其引入内部使用。这不仅避免了数据外泄风险，还兼容企业已批准的模型列表。

量化金融模型的合规文档自动化案例

演讲者进一步展示了OpenProse在量化模型（quant models）监管合规文档生成中的具体应用。由于监管机构要求每1年或3年（或在特定事件变更时）更新量化模型的文档，传统上这需要大量高智商白领人工投入。这些文档需详细说明模型用途、测试条件及上游引用关系。

在演示中，演讲者在Codex环境中启动了该流程。他解释了两个核心输入组件： 1. Kernel（内核）：以Markdown格式编写，面向Agent而非人类阅读。它充当引导程序或索引系统，为Agent提供操作指令和文档查找路径。 2. Program（程序）：同样基于Markdown，包含监管机构和审计师要求的具体合规条款。它定义了最终结果必须满足的合同式条件（contract）。

"The better the harness, the better the model, the faster and the cheaper."

用户只需提供公开的Kernel和自定义的合规Program，Agent即可自动执行复杂的文档生成任务。这一流程证明了OpenProse能够处理高度复杂、条件密集的合规需求，且其性能直接取决于底层模型和Harness的质量。

声明式输出：从“怎么做”到“是什么”的转变

演示的核心在于展示一种声明式（Declarative）的AI交互范式，即用户只需定义最终结果的目标，而非详细规定达成目标的具体步骤。在演示中，团队使用了一个相对廉价的模型以加快运行速度，最终成功生成了关于“Sofa Curve”（一种公开的市场模型）的文档。这一过程证明了代理能够自主完成复杂任务的结构化输出。正如演讲者所言：“the idea is that you're declaring the result rather than declaring how to go about doing it.”（核心思想是你是在声明结果，而不是声明如何去执行它）。这种模式将重点从繁琐的过程控制转移到了对最终交付物的明确定义上，为自动化处理高复杂度文档奠定了基础。

金融合规痛点：高昂的成本与巨大的规模效应

该解决方案主要针对大型银行面临的严峻文档维护挑战。一家拥有约4,000个模型的大型银行，必须每年对这些模型的文档进行重新记录和更新。这一过程不仅耗时费力，而且成本极高。传统手动方式每年造成的经济损失高达1000万至5000万美元。OpenProse通过自动化手段显著降低了这一成本，并取得了“惊人”的效果。为了验证效果，团队引入了现场量化分析师（Quants）对生成文档的质量进行评级。量化专家负责他们擅长的建模工作，而非令人厌烦的监管文书，这种分工极大地提升了团队效率。尽管通过合规、审计和监管机构审查仍是另一场战役，但在成本效益和质量基准测试方面，该方案已展现出显著优势。演讲者指出：“this is a problem that is worth anywhere between 10 to 50 million dollars a year for some of these bigger banks”。

适用边界：探索性对话与可重复工作流的区分

关于OpenProse的适用范围，团队澄清了其与通用聊天机器人（如ChatGPT）的本质区别。虽然生成式AI的爆发部分归功于其无需预先了解目标即可进行探索性对话的特性，但OpenProse并非为此设计。它不适合那些“不知道自己想要什么”的探索阶段，因为像DSPy这样的框架要求用户明确定义返回对象的签名。相反，OpenProse专为需要大量执行、具备高可靠性、可重复性和可审计性的工作流而构建。在这种场景下，用户必须清楚自己的需求。聊天界面并非最佳交互方式，特别是对于不涉及人类对话的工作流。演讲者强调：“you don't want to use this if you're doing a one-off... What this is good for is something you need to do a lot. It needs to be reliable, it has to be repeatable”。

技术架构：组合式契约与事件驱动的语义缓存

在技术实现上，OpenProse强调组合（Composition）而非简单的继承。其核心功能允许将多个契约注入同一次运行中，使代理必须同时满足多项约束。此外，系统还引入了类似React风格记忆化的事件驱动机制。当上游依赖数据发生变化时，系统会自动触发下游组件的更新。这一过程利用了Jev作为语义分类器或语义缓存（Semantic Memoizer）的能力，低成本地判断状态是否过期。传统的代理需要高昂的计算成本来判断状态变化并触发下游任务，而Jev使得这一过程变得极其廉价且高效。虽然完整的语义缓存功能仍在构建中，但组合式契约与事件驱动架构共同构成了框架的核心竞争力。

从模板填充到多智能体工作流契约

演讲者指出，OpenProse 的核心在于利用自然语言（英语）的组合性（composability），这超越了传统 LLM 时代的简单模板填充。早期的编码器或模型只能根据前缀填入预设的固定格式，而 OpenProse 允许用户对整个多智能体工作流进行模板化定义。这种定义的粒度极细，可以指定输出的具体形态（如文章类型、长度）以及输入约束。关键在于引入父代理（Parent Agent）机制，它负责判断子任务是否达成目标并决定何时退出循环。这种架构使得更强的模型能带来更优的结果，因为父代理具备更高的判断力。例如，在一个生成文章的流程中，输入是主题，输出是经过严格约束的文章，直到父代理认为质量达标才停止迭代。

结论

OpenProse通过声明式契约与事件驱动架构，成功将AI交互从“过程控制”转向“结果定义”，有效解决了Agent自我审查偏差及非确定性难题。其在量化金融合规文档自动化等场景展现出显著优势，能将大型银行每年千万至五千万美元的维护成本大幅降低，并实现多轮迭代直至契约对齐的高可靠性。然而，该框架并非通用聊天工具，仅适用于需求明确、需高频执行且具备可审计性的工作流。其核心价值在于利用文本化数据优化Token效率，并支持本地部署以保护机构操作知识。尽管底层提示词仍显庞大且RL训练尚在规划中，但其“自带Harness”的中立性及组合式契约设计已验证了其在复杂企业级自动化中的实用性与可扩展性。