[音乐]

大家好，我是丹。我是Open Pros的创作者。今年雷蒙德和我在一起，还有两位出色的队友、同事，他们都是全方位的杰出创造者和工程师。我稍后会介绍一下他们。先简单背景介绍下我们要展示的内容：2021年4月，也就是五年前，我被Eleuther AI的后台Discord评为“最佳提示词工程师”。当时我认为这是一项将在未来多年极具价值的技能，实际上它确实持续了大概两三年。我说这些是因为大家都知道过去五年发生了巨大变化，但有一件事从未改变：无论最新模型或工具如何演变，我们仍需向系统传达意图。

无论智能体变得多么聪明，始终存在一个挑战：如何将我脑海中的想法提取出来，输入给超级智能体去执行。Open Pros是一种语言、一个框架，它源于我对语言的热爱以及坚信语言是强大的创造力量——这在今天具有字面意义上的真实性。你可以写下一句话，系统就能让它成真。因此问题变成：面对如此强大的机器，你该写下什么句子？五年前的提示词技巧与如今我们推崇的“契约构建”或“契约组合”截然不同。

当模型仅进行下一个词元预测时，提示技巧有好坏之分；几年后，人们手动填充上下文、整合RAG结果和工具调用，称为“上下文工程”；随后自动化框架出现并替你做这些事。最近八到十个月，多项论文将抽象层级再提升一层，框架本身也在快速迭代。例如Anthropic今天早上的演讲展示了“流”的概念——这种自我修改的拓扑结构管理子代理的方式，一年前简直不可想象。

既然提示、上下文和框架都已解决，下一步是什么？这正是我们今天想探讨的：一旦你能命名所需之物，任何框架都能自我塑造、发散或循环以实现目标。关键在于如何最好地“命名”它，我们称之为声明式方法。借鉴经典软件工程概念：我从事软件开发十二年；Jose早期在Google Cloud工作，深刻影响了我们的思路；Raymond则是拥有两个创业经历的博士和“氛围编程”专家。

我们主张组合优于继承，以声明式而非过程式编写提示：告诉系统“做什么”而不是“怎么做”，因为框架会智能决策。若指定具体步骤，反而限制了成本效益和模型潜力——更聪明的模型能自行规划路径。我们将这种描述目标、结果或最终状态的方式称为“契约”，并以可组合方式编写，以便在复杂系统中优雅地管理局部复杂性。

接下来由Raymond讲解具体原理并演示，期间欢迎随时提问举手交流。谢谢丹的分享。我想帮助大家理解Open Pros的定位：请记住两点，第一它是Markdown格式；第二它是事件驱动的而非聊天交互。虽然它有时被称为代理编程语言或框架，但本质全是文本、一个巨大的提示词；我们构建的是事件驱动的多代理工作流。

该项目开源，支持本地通过NPX运行技能模块；我也会演示我构建的托管版本run.pros.md，并提供协助。快速调研一下现场观众：有多少来自金融领域？很好；多少是AI工程师或开发者？也不错。还有更多像产品经理或非技术人员但在使用AI的人群吗？人数较少但也很好，这说明我们的受众广泛。

为什么我要关心这三类受众？对于小型受监管行业，我们观察到一些银行和其他金融服务公司对此感到兴奋。正如我之前所说，一切都是文本形式。因此，我们不需要采购部门，也不需要 IT 部门。你可以使用任何你想要的编码代理、推理引擎、护栏或技术栈，我们实际上可以帮助你创建这些多智能体工作流，而无需向你部署任何其他东西，只需一些 Markdown 文件。这就是“全文本”方式的一个角度或优势。

对于那些不自己编写代码的人来说，基本上如果你能读懂逻辑英语，你就能读懂 Open Prose。因此，我们不会深入探讨该语言的语法细节。从技术上讲，它是一种编程语言并具有语法，但它主要是供人阅读和编辑的，而不是让人从头开始手写。我们不希望用户担心学习模式结构。你可以描述工作内容，让你的代理编写 Prose 程序，这可能会给你一些关于如何编辑它的想法，或者你可能会看到想要更改的内容。然后这个 Prose 程序就变成了可重用的工作流。

对于 AI 工程师和开发人员，我认为使用它的角度在于：它不是一个框架的框架，我们稍后会讨论这一点。即使是该框架的编译器或虚拟机本身也只是一个巨大的提示词（prompt）。你实际上是在植入代码，让编译程序为你工作，或者植入 Codex 来执行此操作。你可以用我们简单的 Markdown 契约表达非常复杂的多智能体工作流，这类似于 Anthropic 的动态代理工作流程。你可以在任何编码代理中做到这一点。

首先关于“这只是 Markdown”的想法，这可以是一个完整的程序作为示例。同样，我不想过于纠结于语法细节，但你基本上可以说：“嘿，这是目标以及它维持的契约。”也就是定义这个契约所维护的内容。这只是一个非常简单的例子。那么，你可以声明什么呢？同样，我不想深入探讨模式、类型和语法，但你在 CLI 中代表你声明的内容被称为“prose write”函数。在我们的应用中，这基本上就是驱动整个应用的代理。你可以创建子代理，为特定的子代理分配特定技能，并提供可用的具体工具。

例如对于搜索功能，我喜欢 Exa 引擎，我认为它们非常出色且我不希望它进行常规网络搜索。我总是希望它使用 Exa 因为对我来说更快更便宜。你可以说：“这是该技能的定义，这是对应的 CLI。”如果找不到这些东西，就不要运行程序。我们不是反过来的做法。因此你可能拥有特定于公司或组织的技能。然后本质上，你可以将其视为将程序连接在一起的方式；如果它缺少所有依赖项，就不要编译。

显然还有这个程序的输入是什么，以及该程序必须交付的输出是什么，即契约必须交付的内容。再次强调，如果有人想深入探讨丹是如何构建它的细节：运行时本身也是一个巨大的提示词。所以我技能或提示中最喜欢的句子之一是：“你是编译器。”这不是比喻，你就是编译器。而且它似乎有效。

还有事件驱动的理念。我们要摆脱“一切皆对话、一切皆聊天”的想法，构建事件驱动系统。为了比较这些不同的工作流树：某事发生可能是定时任务、GitHub 上打开了新问题或提交了新 PR，或者你有某种 Webhook 系统（比如 Stripe 出问题了）。现在你可以触发你表达的工作流，端到端地处理整个事情并履行契约。

这种构建“任务”的理念允许你自己用自己的代理和系统设置它，而我在 run.prose.md 中构建的是“任务等于契约加触发器”的概念。因此，触发器可以是极其简单的如时间表（例如每天运行此任务）。但目前我们在应用中实现的主要两个触发器是 Webhook 和定时任务。Webhook 涵盖了广泛的内容，如整个 Slack 应用或 GitHub 都基于 Webhook。如果希望我们使其他触发器更容易使用，欢迎提供反馈。

从该触发器开始，你可以对这些工作流进行分类处理。因此你可以开始构建代码工厂，通过创建 Prose 程序的常驻任务来实现。我想展示并确保在活动前准备好的一项功能是 Webhook，特别是使用 GitHub 事件，并且我一直在强迫自己使用该程序来开发该程序。因此系统中现有的一个主要示例是：任何进入的 GitHub 问题，你都要编写一个 Prose 程序来尝试解决该问题。你可以使其复杂或简单，可以是多智能体工作流，具有必须遵循的特定技能或使用模型。

基本上输入就是那个问题本身，输出是一个提交（commit）。它必须一直推进直到为你完成这件事。类似地，我将具体展示另一个例子：进行 PR 审查的事件驱动对抗性审查。我不知道你们是否听说过，其中一件让我觉得有趣的事情是……

今天早上在 Anthropic 的工作坊上，他们讨论了自我审查的挑战。比如，你在 Claude Code 中会说：“好吧，我要让你推送到生产环境了，但能不能再帮我检查一遍？”由于存在偏见，模型倾向于认为自己做得很好。人类也是如此。因此，我将展示一种工作流，本质上是通过拉取请求让构建这些代理的应用程序本身产生反向压力。

在过渡期间，切换到 Web 应用时有人提问吗？“没有问题太愚蠢的。”“那是手还是手机？我看不清这里的灯光。”“也许没有吧。”“好的，请说。”远处有人举手。“这是一个很好的问题。我来回答这个问题。”“是的，你应该接这个茬。”

我之前提到过，“是什么”和“怎么做”是两个不同的概念。声明结果，而将具体方法留白，让代理自行决定。但在某些情况下，正如你所说，你可能确实想介入“怎么做”。事实上，我们有一个功能语法允许你固定具体方法。你可以最初松散地声明目标，让智能代理运行并找出实现路径。

一旦它完成了这项工作，你可以说：“这是代理的执行轨迹。”我们可以将这条轨迹编入代码或“收缩包装”成具体的执行步骤。这样做的好处是降低完成工作流的成本。你开始使用昂贵的模型来探索方案，然后使其更具体、更具确定性。

当我们说所有内容都是 Markdown 时，这是起点，但你也可以逐步转向更具体的过程式指令风格。对此我有几点评论：我们可以将一次完美的会话转化为可复用的工作流，比如“这是我用过最好的 Claude Code 会话”。

这些工具具有非确定性。人们展示的所谓固定且稳定的端点，实际上随着各大公司算力受限而不断变化。此外还有期望值的变化：第一次尝试 Fable 等工具时令人惊叹，你希望每次都能得到这种效果。但随着时间推移，期望值改变，可靠性成为问题。

你可以将一次极好的会话编入代码固化下来。但为了给予 Dan 更多赞誉，构建框架不仅仅是你看到的 Markdown 那么简单。那是冰山一角。上次我检查时，完整的系统提示或技能说明接近七万到八万个 token，甚至更长。我们正在尝试清理它……

既然代理变得更聪明了，我们可以让提示更短一些。我们基本上有一个完整的类型系统，用清晰的类型系统和特定的代理交付指令覆盖 Markdown。但这正是我们不干预的地方：Claude Code 运行时有自己的子代理系统，我们不想将其与特定于 Claude Code 的提示混淆，因为 Codex 有完全不同的子代理集。

我们更像是一个元框架（meta harness），我们希望用户自带框架，而不是成为那个框架本身。我们是被框架编译的对象。这回答了你的问题吗？好的。如果你想尝试，二维码指向 run.prose.md。我想展示几件事：首先是 Prose 程序的编辑模式。

这在技术上确实是 Markdown，Dan 用各种类型重写了 H3 标题头。但让人从头学习这种语法并编写并不是重点。虽然执行该程序的所有内容都在这里，对于真正的技术迷来说，你可以看到我已经提取了 Markdown 文件的前置元数据（front matter），这实际上就是云端发生的所有事情。

我可以将这个程序导出为纯 Markdown 文件发给朋友，他们上传到云端的方式完全相同。为了保持组合性并坚持纯 Markdown 的理念……总之，虽然这是核心内容且希望你阅读它，但它不是入口点。所以我构建了一个代理来与我对话：“嗨，我是 Prose。”

“你今天希望完成什么任务？”“每次我有新的拉取请求时，我希望你在我的 run-prose 仓库中为我编写一个 Prose 程序。你要扮演一位不喜欢 AI 生成代码的脾气暴躁的高级开发者来进行审查。”“当然可以，请稍等。”

我要静音了。它在运行并试图解决这个问题。任何涉及金钱的操作都需要确认，这是最佳实践。是的，我必须确认，因为该操作会产生费用。这就是 Prose 的推理函数（reasoning function）。它基本上接受我的查询，并生成一个新的程序，包括所有连接逻辑。这一步需要一点时间。

在这个运行的同时，我会展示手动操作的流程。这可以在“Jobs”（任务）选项卡中进行。我不知道为什么这里会中断。在 Jobs 选项中，我们可以点击此处创建新任务。“Schedule”（计划）本质上就是一个 Cron 定时任务。我们还提供了一个开放式的 Webhook，这意味着你可以使用我们特定的 Webhook，或者将我们的系统连接以监听你的 Webhook。

对于 GitHub 的 Pull Requests（拉取请求），我们简化了这一流程，同样在 run.pros 中配置。我已经预置了这个契约：“好的，你要审查我的代码。”然后你可以选择使用的模型，目前我们支持 OpenAI 的前三大模型，后续会添加更多。创建并部署后，我想展示的是如何利用它作为“反向压力”机制。

请注意不要过于纠结于上方的具体内容，我想展示的是工作量规模。这些任务大多来自三四天前。在短短几天内，系统处理了数十个 PRs。每当我为这个 GitHub Webhook 功能提出新需求时，每一个请求都会触发一系列审查代理。有些很简单，一次通过；而有些则经历了多达 14 轮审查，直到代理们达成一致才放行。

就在今天，我注意到一个我不满意的地方，并指示在预发服务器上不要触碰生产环境。我希望代理按照特定方式触发系统本身进行审查，结果开发版和生产版的代码给出了不同的评价。现在运行的代理必须将这种反馈纳入考量，直到其开发者的代理们采纳这些意见为止。

这与其它基于聊天或智能体的流程不同之处在于，所有这些结果都与契约进行了比对。你可以将其视为每次都是一个新的会话，并根据你声明式编写的基准进行测试。正如 Raymond 之前提到的，这使模型摆脱了“自我确认循环”，即你不希望同一个模型检查它自己完成的工作。通过生成新会话并将其与契约比对，这是一种更好的模式。

有人问这是否是像 Jeff 这样的单步分类器的好机会？是的，我们正在准备很多好东西。在决策模型中，你有一个理想状态的契约和一个混乱的现实世界状态，你可以应用像 Jeff 这样的通用决策模型来判断是否通过。这非常令人兴奋。

但这与 OpenProse 的语言特性有关吗？OpenProse 基于 Markdown，而 Jeff 这类模型不具备生成能力。我认为 OpenProse 在两个地方适合与这些决策模型结合：一是在后端。OpenProse 的弱点在于它让代理自行判断“我已满足契约”，如果在不同模型上运行，结果可能大相径庭。

因此，像 Jeff 这样的决策模型或“系统一”模型非常适合作为任务结束时的验证器，快速且廉价。另一个我想构建的相关功能是路由器：为什么我要手动点击按钮来区分 Issue 任务和 PR 审查任务？为什么不直接说：“所有进入的 GitHub 事件，请解决 Issue 并审查 PR？”

有人开玩笑说不该给他们更多关于游戏的想法。另一个热门话题是：既然我们有这么多针对契约的运行记录，为什么不直接进行强化学习（RL）？从工程角度来看，所有数据都是文本形式，这对于 RL 来说非常完美。虽然我们现在还没做，但这绝对是我们正在考虑的方向。

我们正在与各种潜在客户交谈，讨论一旦将所有内容写成文本格式后的情况。这确实对强化学习（RL）要好得多。虽然目前我们尚未达到需要重视这一点的规模，但如果你托管模型并拥有约十万个token的前缀，就可以构建更高效的Token表示形式。如果有人想在OpenPros中处理万亿级别的Token，我们很乐意为你优化它。

回到正题，感谢大家提出的好问题。现在我们有了“挑剔的高级拉取请求审查”功能。关键理念是代理为我们完成了所有工作。部署此作业后，每当收到新的PR时就会开始产生费用，因此我需要点击确认。一旦部署完成，回到作业页面查看，加载后你会看到“Grumpy AI skeptic PR review”位于顶部或底部。

之前我一直在练习这个功能。我负责run.pros.md文件，如果遇到任何问题，请不要告诉我的老板，直接发给我即可。我的代理会为你处理一切。我对这种基于事件系统的简单易用方式感到非常兴奋，如果你想查看其他触发器或功能，那对我来说也很有趣。

你完全不需要使用托管服务，可以通过NPM安装技能包：npx skills add open-prose。接下来Dan将通过一个针对金融领域朋友的具体示例，在Codex中展示这一功能，并借此机会深入讲解其底层工作原理。

将OpenProse在云端运行起来很有趣。我们与多位客户和潜在客户探讨过，这是一个可以在内部构建的框架、语言或模式，并可在本地部署。我们鼓励你在云端尝试和体验，但如果你希望在组织内部实施，最有趣的应用场景是基于开源模型和本地环境（Bring Your Own Harness）构建应用层。

这样你就可以在内部建立全栈系统，无需将任何数据发送给大型实验室。比数据安全更重要的是机构知识。我们将OpenProse视为制度化的操作知识和文档，类似于标准作业程序（SOP）。你不希望将这些核心流程泄露给大型科技公司。

OpenProse采用开源核心模式，拥有宽松许可证，可引入内部使用。许多大公司已经这样做。你可以自带模型环境，并使用公司批准的模型，无需担心将数据或组织知识“扔过墙”。这是一个我们为客户构建的工作流示例。

该客户有兴趣使用OpenProse来记录其量化模型文档。熟悉这一领域的人知道，量化模型有各种监管承诺：每三年、每年或在特定事件发生时，都需要更新文档。这通常是一个需要高素质白领人员投入大量精力进行人工编写和审查的过程。

这些专业人士每年都要花费相当一部分时间撰写文档，记录模型的用途、测试条件、上游引用的其他模型以及其他监管机构、内部审计和合规部门要求的复杂内容。我们发现这种流程非常成功，因为监管文档本质上就像OpenProse程序——即用自然语言编写的要求。

我在Codex中启动演示，你也可以在Cloud Code或本地环境中运行。关键在于它与具体环境无关（Harness Agnostic）。我们只需引导内核，然后运行OpenProse程序。在运行时，我可以展示内核和程序的样貌。

这是内核部分，采用Markdown格式，并非设计给人阅读的（因为之前美观的格式曾引起抱怨），而是供代理读取的操作指令。你可以将其视为引导程序、解析路径或索引系统，帮助代理找到所需的其他文档。

程序本身在Codex中看起来非常相似，同样使用Markdown格式，包含监管机构、合规部门和审计员要求的大量内容。它指定了最终结果应符合的合同理想状态。你只需传入公开发布的内核，并编写任何需要满足复杂条件的程序或合同即可。

代理将自动执行任务。环境越好、模型越强，处理速度就越快，成本也就越低。

他们会生成输出结果。嗯，但核心思想是你是在声明最终的结果，而不是声明如何去执行它。让我们看看能不能回溯一下。我们在这里使用了一个相对便宜的模型来运行，以便加快速度。嗯，但它仍然在正常工作。哦，看起来它快要完成了。所以，这就是它生成的文档。在这个例子中，我们正在为“沙发曲线”（Sofa Curve）创建文档。这是一个公开的模型，所以我们没有展示任何内部银行数据。嗯，我不知道……请举手。房间里有没有量化分析师？来审核一下这份文档吧。大家觉得这看起来怎么样？是的，[笑声] 好吧。嗯，我们会稍后去找你们。

大家要知道，这是必须定期为每个模型生成的文档。一家大型银行大约有 4000 个模型，它们每年都需要重新记录文档，这是一个价值在每年 1000 万到 5000 万美元之间的问题，对于某些大型银行而言。而我们在以更低的成本为他们做这件事方面取得了巨大成功。嗯，当然，要通过合规部门、审计师和监管机构的审核是另一场战斗，显然你们对此都很熟悉。但我们可以将结果与历史数据进行基准测试，也可以与团队完成这项工作所需的时间进行对比。

我们有现场的量化分析师能够对这些结果进行评估，并让我们了解模型的表现如何。我们发现效果令人震惊地好——比传统的手动方式便宜得多，而且效果好得惊人。有什么问题吗？有像量化分析师这样的人…… >> 做量化分析师擅长的事。>> 构建模型。>> 而不是监管文件，那可能不太有趣。我不是量化分析师…… >> [鼻息声]>> 有什么问题吗？很好的问题。嗯，是的。

实际上，雷蒙德作为内核的一部分展示了一下聊天代理。在路径深处的 Markdown 中，我们有最佳实践指南。这些是你声明结果时想要做的事情类型。嗯，还有反模式，即你不应该做的事情。所以，是的，确实存在一种情况，你不需要输入整个契约本身，而是进行迭代。这就是雷蒙德通过另一个代理展示的内容，该代理遵循我们的最佳实践指南来创建契约。但是，嗯，我认为从人们脑海中提取意图是困难的部分，而这只是其中的一部分。这肯定不是全部…… >> 是的。

我有一个稍微长一点的、我不想说得太长的抱怨。我们只有 5 分钟了。但这与聊天应用之所以如此迅速爆发有关，我认为这是很大一部分原因：你不需要了解你要找的任何东西，只需开始与 ChatGPT 互动即可。生成式 AI 的魔力在于让它回应你，对吧？所以，如果你处于那种阶段——你真的甚至不知道你要谈论的内容的形状，或者你不确定你到底在寻找什么——那么 OpenProse 可能不是最好的地方。嗯，我是一个非常老派的 DSPy 用户，关于 DSPy 我的玩笑是：“哦不，我现在必须知道我想要什么了，对吧？”因为 DSPy 的整个理念是你必须创建你想要的东西的签名。

当你看到类似的东西时，你会觉得：“这太棒了。”然后你坐下来想，“哦，其实我不知道我想做什么。”所以我认为 OpenProse 比像 DSPy（原文误拼为 DS fire）这样的东西宽松得多，在 DSPy 中你 literally 必须说出返回对象的签名，否则什么都不会发生。嗯，但我会说内置的代理希望能帮助解决一些这个问题：你可以打开语音功能并问“你能做什么？”它几乎可以做你在应用中做的任何事情。当然，对于任何涉及费用的操作，我们有硬编码的确认机制。显然，我们希望人们点击按钮来执行这些操作。

我认为这也与“去工作化”（jobification）有关：聊天不是一个很好的界面，而像 RLHF 那样被训练成令人信服的聊天伙伴的代理，对于完全没有人类对话参与的工作流程来说，并不一定是最好的 AI 类型。>> 让我插一句：像我们告诉人们的那样，如果你是一次性操作，就不想使用这个；如果是聊天，那就完美了。如果你在探索模式……这种工具适合的是你需要频繁做的事情。它需要可靠、可重复、可审计。这些类型的工作流程正是 OpenProse 构建和旨在服务的，因此这里隐含着你确实知道你需要什么。>> 哦，我们收到了一个真正的量化分析师的问题。

之前我提到过这一点，我不愿意称之为继承，我更愿意称之为组合（composition）。事实上，框架和模式本身的核心特性就是它是为了可组合性而构建的。所以是的，将多个契约注入到同一个运行中，让代理必须满足其中的许多项，这是这里的核心部分。另一半是事件驱动的部分……也许看起来有点像你们所说的继承？我认为这更像是嗯，我不知道你是否熟悉类似 React 风格的记忆化（memoization），其中你有某些组件。它仍然是组合。你有一些具有上游依赖关系的组件，当其中一个的数据发生变化时，当然会向下传递到所有下游组件。

这是 Jev 非常令人兴奋的地方，决策模型也非常令人兴奋，因为我们构建了那个系统，代理试图确定状态是否发生了变化。如果上游依赖的状态发生变化，我们是否启动下游依赖？但这运行起来非常昂贵。而 Jev 突然变成了这种非常便宜的语义分类器或语义记忆化机制，你可以把它想象成一个缓存。Jev 决定某些东西何时过期，现在它启动从那里向下的所有内容。所以这是框架的另一种核心组件。除了 Jev 部分，我们仍在构建它。是的，这里没有魔法。

这全都是英语，都是语言。没错，这正是组合性（composability）发挥作用的地方。你提到的另一个重点是，这不仅仅是一个模板。也就是说，即使在大型语言模型（LLM）出现之前，或者在不太早期的 LLM 甚至编码器时代，人们就可以通过前缀模板来填充内容。但在这里的问题是：“你能对什么进行模板化？”因此，你可以将整个多智能体工作流（multi-agent workflow）作为模板。

我给出的一个简单例子是，你可以规定所需的输出是一篇文章。比如文章的类型、长度等约束条件，而输入则是主题。直到你得到一篇让我满意的文章为止，父智能体（parent agent）会判断何时退出。这就是为什么使用更强的模型会比弱模型产生更好的结果的原因。我拥有一个负责研究的子智能体，该智能体拥有我的访问命令行界面（CLI）的权限以及使用 CLI 的技能，因为我不希望它随意进行网络搜索。

我还拥有一个负责写作的子智能体，它具备我最近写的十篇优秀文章作为参考，并被告知要模仿这种风格。此外还有一个负责校对编辑的子智能体。这一切可能只需要大约 100 行的 Markdown，但完成它可能需要花费十个小时。

这里需要强调的重点是“契约组合”（contract composition）。虽然这些概念早已存在，比如任何拖拽式的工作流构建器都能实现类似功能，但这里的思维方式不同。当你从“契约有向无环图”（DAG of contracts）的角度来思考时，你可以将中间步骤视为检查点。

当某个中间步骤满足契约要求时，流程就会继续推进；一旦达成该契约，下一个环节便会启动，直到所有相关契约都被履行。因此，你仍然可以通过组合沿途的中间契约来声明“如何到达那里”，同时让智能体在执行这些中间步骤时保持一定的灵活性。

没错，还有其形态结构。例如，当 Claude 发布动态工作流时，他们有一篇博客文章列出了六种类型：一种是扇出/扇入（fan out/fan in）并结合子智能体的映射归约；另一种是对抗式审查（adversarial review）；还有一种是循环直到满足某个条件。所有这些形态都可以用 Prose 程序来表达，并在任何智能体上运行。

这意味着你可以无代码地模板化多智能体工作流的形态结构。这之所以成为可能，是因为智能体擅长自我管理，且大多数框架都支持子智能体。如果你运行的是没有子智能体的普通 Vanilla Pi（据我上次检查），你就需要为它添加子智能体以执行更复杂的工作流。

基本上，任何满足“拥有子智能体”这一要求的框架都可以做到这一点。“子智能体。”是的，对于大多数情况来说，“上下文管理”也是关键因素之一。其实你甚至不需要 Bash 环境，我们也可以在代码模式下通过 VM 隔离来运行这些任务。

还有其他问题吗？我们可以把时间还给大家十分钟。这个方案基于我多年的工程经验，以及处理那些有时不善于表达需求、而另一些人又非常擅长表达需求的客户经历。此外，我们在内部进行了基准测试，并运行了一种进化算法来缩小内核范围，通过观察它们是否能符合规范来进行优化。

因此，这是基于实践和实证结果的。“没错，你可以将其作为规格说明书（spec）。比如 Matt Pocock 的规范。你知道的，我为了调侃他专门构建了一个叫‘Auto Pocock’的东西。”这基本上是我证明我的技能连接方式有效的一种方法。他有一个工作流是“拷问我”，然后提出各种问题，接着进行 TDD（测试驱动开发）等其他环节。

你可以将整个流程放入一个 Prose 程序中，只需声明执行 Matt Pocock 的工作流即可。在程序的每个阶段，子智能体都必须加载序列中的下一个技能。“所以是的，绝对可以。”“有人称之为谱系驱动开发（spectrum-driven development），虽然我并没有这么称呼它，但本质上它就是。”

我很想让你试试这个。你可以尝试一下，或者结束后来找我讨论。无论你有什么样的谱系驱动开发规范，我们都可以将其与 Boot Kernel Prose 进行组合运行，看看效果如何。我认为它会表现相当不错。这是一个很好的灵感来源。我还没有尝试过谱系驱动开发的契约，我很想坐下来试试，看看它是会覆盖原有逻辑还是会产生冲突。

“那将很有趣。”“这里有一个……”“看看不同的技能会如何影响结果，把它抛出去试试。”“这是我们目前观察到的一点：软件工程师正在使用 Open Prose 开发软件。但更多用户将其用于运维、产品管理，以及量化模型文档等非软件工程领域。”

我认为这是因为 Markdown 文档对于非工程师来说更具吸引力，结果也是如此。还有其他问题吗？谢谢大家，感谢你们的时间。“[掌声]”