Barndoor 收购 Diaphora，让受治理的 AI 工作流接受考验

Barndoor 于 9 月 16 日收购了 Diaphora，在生产环境挑战尚未解决之际，将两种企业 AI 路线整合到同一体系中。此次 Barndoor 收购 Diaphora，将 Diaphora 的受约束工作流引擎与 Barndoor 的访问、策略和审计控制能力结合起来。交易金额未披露。

这笔交易之所以重要，是因为 Barndoor 正从治理 AI 系统与企业工具之间的连接，进一步扩展到治理建立在这些连接之上的业务流程执行。其角色由安全检查点扩展为工作流平台。

矛盾点在于灵活的智能体与可预测的自动化之间。智能体可随条件变化调整计划，但这种自由也使其行为更难测试。传统工作流引擎表现一致，却难以处理需要理解或判断的工作。

Barndoor 认为 Diaphora 的技术能够连接这两种模式。其拟推出的 Blueprints 定义固定的工作流步骤，同时将大语言模型的决策限制在指定节点。这种方法更接近确定性工作流系统，而非不受限制的智能体循环。

这种架构听起来适合注重安全的企业。然而，两家公司尚未发布生产环境基准、部署数量或独立可靠性测量数据。因此，这项收购提出了明确的技术押注，但尚未证明其运营效果。

Barndoor 收购 Diaphora 带来了什么变化

Barndoor 收购的是执行层，而不只是新增一项安全功能。

总部位于纽约的 Barndoor 通过 9 月 16 日的交易公告宣布收购。Diaphora 全体团队将加入 Barndoor，两家公司将这笔交易称为“spin-in”。

Diaphora 最初是由 Simone Pezzano 开发的独立项目。Jay Parisi 后来参与了这项技术的协作，Barndoor CEO Oren Michels 则担任顾问。这种既有关系降低了部分整合风险，因为双方团队并非在竞争性出售后才首次接触。

此次收购围绕 Frags 展开，后者是用于构建 AI 工作流的开源运行时。运行时是执行已定义程序或工作流的软件层。Frags 使用 Frags Modeling Language，即 FML，来规定模型、工具和结构化步骤出现的位置。

FML 是一种领域专用语言，也就是说，它描述的是一类狭窄的任务，而非通用编程语言。其公开的语言文档说明，该语言支持结构化输出、依赖会话、模式、工具和 MCP 连接。

MCP，即 Model Context Protocol，为 AI 应用连接外部工具和数据提供了一种标准方式。标准化连接简化了集成，但也扩大了权限、监控和策略执行的覆盖范围。

Barndoor 已将自身定位于 AI 客户端与这些连接资源之间。该公司表示，每项请求都可经过身份验证、策略检查、敏感数据扫描、计量和日志记录。Diaphora 则增加了一套系统，用于定义在获得访问权限后应如何执行。

规划中的整合产品将其可复用工作流称为 Blueprints。每个 Blueprint 都通过明确的步骤序列连接工具和数据。模型处理选定的决策，其余执行则由预先确定的逻辑控制。

这种差异在运营工作流中很重要。要求模型“解决这个账单问题”会赋予它广泛的解释自由。Blueprint 则可以定义要检索哪些记录、要验证哪些条件，以及哪项操作需要模型判断。

Barndoor 表示，当 Blueprint 无法完成必要步骤时，应当停止。它应识别问题，而不是编造一个看似合理的替代方案。在客户针对各种生产工作负载发布证据前，这种行为仍只是公司主张。

据 Barndoor 称，底层 Frags 运行时和 FML 将继续保持开源。因此，开发者仍应能够检查、扩展并为这项执行技术作出贡献。

开放代码并不会自动让已部署的工作流变得安全。企业仍必须审查配置、凭证、依赖项、模型行为，以及围绕每个连接系统制定的策略。不过，与完全封闭的运行时相比，这确实使工作流引擎更易于审查。

此次收购也改变了 Barndoor 的商业定位。它如今可面向需要构建 AI 自动化的团队，而不只服务于希望治理既有智能体的安全团队。这带来了更大的机会，同时也意味着显著增加的实施负担。

为什么治理正在进入工作流执行层

当模型能够修改记录，而不只是生成文本时，企业 AI 治理的重要性将显著提升。

起草回答的聊天机器人带来的是审查问题。更新客户记录的智能体带来的则是授权问题。后者需要围绕身份、工具、数据、操作和支出设置边界。

这一区别解释了为何 Barndoor 收购 Diaphora 会在此时发生。企业已花费数年时间，通过助手和孤立演示测试生成式 AI。如今，许多企业希望这些系统能跨应用执行多步骤工作。

Barndoor 的原始产品聚焦于模型和 MCP 服务器周边的访问与可见性。其公开发布紧随 2025 年 5 月据报道完成的 1,360 万美元种子轮融资之后。Crosslink Capital 领投该轮融资。

网关可以决定智能体是否能够调用工具，也可以记录请求并执行数据策略。但这些控制并不一定能判断整个操作序列是否构成获批的业务流程。

以客户通话后的销售工作流为例。该流程可能包括总结对话、更新账户、安排跟进以及通知内部团队。每项单独操作都可能获得许可，但整个序列仍可能包含错误。

摘要可能被附加到错误的账户。推断出的日期可能造成不正确的承诺。通知也可能向更广泛的渠道泄露敏感细节。因此，治理必须同时涵盖访问和执行逻辑。

这一需求与既有风险指引一致。美国国家标准与技术研究院的 AI 风险管理框架将治理视为管理已部署 AI 系统的持续性组成部分。该框架也强调定义 AI 系统支持的任务。

当自主智能体在执行过程中自行规划路径时，这种以任务为中心的治理会变得更困难。当组织能够检查稳定的工作流定义、约束权限并审查异常情况时，治理则更易于管理。

Diaphora 的架构试图将判断与执行分离。模型负责受限决策，传统逻辑负责已知步骤。这种混合设计保留了一定灵活性，同时避免让每项操作都成为新的模型选择。

这种方法也带来了更清晰的责任归属。业务团队可以定义所需流程，开发者可以检查技术方案，安全团队可以控制访问。审计人员随后可以检查与同一工作流定义相关联的记录。

Barndoor 表示，员工只能发现和运行获其角色授权的 Blueprints。该公司还称，自动化将继承针对其工具、模型和数据的控制。这将避免为每位员工单独配置每个底层系统的权限。

这种分发模式具有战略重要性。构建一个可用的自动化，与在整个组织内安全分发它是不同的事。更广泛的分发会成倍增加用户、凭证、数据路径、异常情况和潜在错误的数量。

Barndoor 客户 Syndio 为公告提供了主要的支持性观点。CTO Nimrod Vered 表示，可预测的执行和可见性将帮助公司更广泛地部署工作流。这一表态显示了客户兴趣，但并非独立的性能研究。

因此，这项收购改变了 Barndoor 面临的问题。该公司不再只需证明自己能够阻止或记录单项请求，还必须证明受治理的工作流能够在企业规模下保持可用、可靠且易于维护。

Blueprints 以智能体自由换取可预测的控制

整合后的架构将不受限制的自主性视为可重复业务流程中的一种风险。

Diaphora 的核心理念并非消除大语言模型，而是限制它们可作出决策的位置。这一边界将 Blueprint 与动态选择每一步的智能体区分开来。

Michels 通过将计划与已定义的结果路径作对比，概括了这种区别。他的观点是，许多智能体系统从一个预期计划开始，而 Blueprint 则确立实际执行的步骤。

这是此次收购的核心技术机制。工作流可在理解能力有价值时调用模型，例如对客户问题进行分类；而在一致性至关重要时，则可使用确定性代码，例如检查必填字段。

由此形成的系统既不是经典的机器人流程自动化，也不是完全自主的智能体。它是包含概率性组件的结构化工作流。概率性意味着，模型可能针对相似输入产生不同输出。

公告中的一个示例涉及纠正账单错误。典型助手可能识别问题，并为员工起草建议。Blueprint 则可以检索相关数据、验证条件，并提交经授权的更正。

这个示例也体现了风险。账单操作可能影响营收、客户信任和财务记录。在写入变更前，一个可靠系统需要的不仅是一份看似令人信服的模型回复。

工作流应验证标识符、金额、策略条件和授权。若后果足够重大，也应提供审批边界。Barndoor 尚未针对这一示例发布详细的参考实现。

另一个场景涉及季度客户健康度审查。该工作流可能从四个分别受控的系统中检索合同、使用数据、支持历史和账单信息。

执行审查的员工可能无需直接访问每个数据源。相反，经授权的工作流可以为该特定目的检索获许可的信息。这种设计在支持跨系统分析的同时，限制了广泛凭证的使用。

此类工作流还需要谨慎的输出控制。获授权查看最终健康度评估的用户，并不自动获授权查看每条底层记录。系统必须在检索、推理和呈现过程中始终保留这些区分。

Barndoor 表示，其基于角色的访问控制将管理哪些员工能够发现和执行每个 Blueprint。该公司还承诺提供记录，显示自动化访问、修改了什么，以及产生了多少成本。

这些记录可帮助团队调查事故并监测采用情况。其价值将取决于细节程度、保留期限、导出选项，以及与现有安全系统的集成。若日志仅记录成功的工具调用，便会遗漏重要的推理失败。

该架构也引出了版本管理问题。工作流会变化，模型会变化，提示词会变化，所连接应用的架构也会变化。若团队希望开展可复现的调查，执行记录必须标明所涉及的确切版本。

模型更新带来了尤为棘手的问题。固定的 Blueprint 可以约束模型的作用范围，但无法保证模型输出会始终一致。团队仍需针对每个判断节点进行评估。

Frags 或许能为这些调用提供结构，但结构并不等同于语义正确性。模型可能按要求的 schema 返回有效数据，却做出了错误分类。

Barndoor 的赌注在于：只要周边流程保持受控，企业就会接受有限的不确定性。这比承诺生成式模型能够实现完全确定性更为现实。

这也比业界广泛推崇的宏大代理愿景更具约束性。开放式代理可以在任务中发现新的路径；Blueprint 则牺牲一部分适应性，以便让部署更易于理解和治理。

对于重复性的企业工作，这种取舍可能是合理的。当流程会更改客户、员工或财务记录时，组织通常更看重执行的一致性，而非新颖性。

更棘手的问题在于边缘情况。当真实条件偏离设计时，约束严格的工作流可能会频繁停止；约束宽松的工作流或许能继续运行，但风险更高。

生产环境证据必须揭示 Barndoor 将界限设在何处。最佳设计不会将自由度或刚性中的任何一方最大化，而是应将每类决策交给最适合的机制处理。

真正的对手是不受约束的代理自主性

Barndoor 所竞争的是一种架构假设：更强大的模型能够安全地规划并执行完整工作流。

企业自动化市场涵盖成熟的工作流产品、新兴代理框架、集成平台和云套件。每一类产品都基于不同的控制假设来应对同一个问题。

传统工作流引擎始于一个明确的流程。开发者会指定状态转换、错误处理、重试和权限。这种方法支持测试与审计，但需要有人对流程进行建模。

代理框架通常从目标出发。模型利用可用上下文选择工具，并决定下一步行动。这能处理结构较弱的工作，但执行路径也更难预测。

Temporal 展现了这一区分中偏传统的一侧。其 agent architecture 将非确定性的输入和输出置于确定性工作流代码之外。这种分离支持恢复，因为工作流历史可以重放。

Barndoor 和 Diaphora 遵循相关原则，尽管其产品设计和目标用户不同。对于传统逻辑能够更可靠执行的步骤，模型不应掌握控制权。

其他平台将代理编排与追踪、评估和策略控制相结合。这些产品可能提供更广泛的开发生态或更深入的集成。Barndoor 的差异化取决于能否将工作流定义与集中式治理结合起来。

这一定位给两类厂商带来压力。治理厂商必须决定，仅凭访问控制是否足以提供价值；工作流厂商则必须决定，传统编排能否在不依赖专用语言的情况下容纳模型判断。

此次收购使 Barndoor 能够在同一平台上回答这两个问题。客户可以构建 Blueprint，将其作为受治理的 MCP 工具公开，按角色分发，并通过同一控制层监测执行情况。

这一整合路径可以减少不同产品之间的协调工作，但也可能增加对平台的依赖。客户需要评估工作流定义是否仍具备可移植性，以及 Frags 在 Barndoor 的商业服务之外是否依然有用。

开源承诺有助于缓解这一担忧，但其持久性至关重要。买方应关注代码仓库活跃度、许可证变化、外部贡献者、发布节奏，以及与独立基础设施的兼容性。

开源也提供了技术验证的路径。安全团队可以检查工作流计划如何被解析和执行；研究人员可以测试在封闭产品中可能较少受到关注的故障条件。

但治理层本身包含了商业价值中的很大一部分。即使工作流运行时是开源的，策略决策、身份集成、监控、数据丢失防护和企业支持仍可作为托管能力提供。

这种开放核心模式在基础设施软件中很常见。社区获得可检查的引擎，而企业则购买集中化运营与控制能力。成功取决于如何让双方都保持价值，同时不削弱公共项目。

Barndoor 还必须与内部工程团队竞争。大型组织已经在使用工作流引擎、身份系统、API 网关和可观测性平台。它们可以通过组合现有组件来构建受治理的代理技术栈。

整合产品必须节省足够多的集成与维护工作，才能证明引入另一个控制平面的合理性。它还需要与企业无法替换的系统共存。

这使互操作性成为此次交易的核心。FML 对工具、schema 和 MCP 的支持提供了有用的基础模块。生产环境买方仍会询问标准身份协议、事件系统、审批服务和现有工作流引擎。

因此，竞争问题远不止功能对比。企业必须选择策略存放在哪里、工作流在哪里定义，以及模型判断在哪里进入执行过程。

Barndoor 的答案是将这些边界放得更近。它直接替代了让每个代理框架自行定义权限、工作流逻辑和运营记录的做法。

此次收购尚未证明的事情

一个连贯的架构并不能证明产品能够处理企业级规模、异常情况或对抗性输入。

该公告提供了产品描述和客户评论作为支撑，但未披露收购价格、Diaphora 的营收、部署数量或独立使用指标。

它也没有提供可靠性对比基准。读者无法判断，在现实条件下，Blueprints 成功完成、安全停止或产生错误决策的频率分别是多少。

这一证据缺口并不会否定该架构，而是界定了尚未验证的部分。买方应区分产品的预期行为与已测量的性能。

首要担忧是过度代理能力，即系统获得了超出任务所需的功能或权限。OWASP guidance 建议将工具、权限和自主性限制在必要范围内。

Blueprints 似乎正是围绕这一原则设计的。然而，即使序列定义清晰，仍可能包含权限过高的工具。计费工作流不应仅因步骤可预测，就获得不受限制的数据库访问权限。

提示注入带来另一项风险。恶意指令可能出现在文档、消息或检索到的网页内容中。模型可能将这些内容解读为命令，并尝试执行非预期操作。

确定性的工作流缩小了可选路径，但不会自动消除恶意输入。系统必须在每一个模型决策点区分不受信任内容与授权指令。

数据泄露同样仍有可能。工作流可能正确检索信息，却向模型传递了过多上下文；它也可能在日志、错误报告或生成输出中包含敏感内容。

Barndoor 表示，它可以在信息到达模型或工具之前应用数据丢失防护。客户需要测试覆盖结构化记录、附件、转换后的文本，以及由多个来源组合而成的内容。

成本控制也构成相关挑战。固定工作流可能包含循环、重试或重复的模型调用。因此，即使每次单独调用都已获授权，意外输入仍可能造成过度支出。

团队应测试最大调用次数、token 预算、超时和重试规则。他们还应区分短暂的应用故障与不应重试的模型决策。

人工审批并非通用解决方案。频繁弹出的请求可能沦为几乎不经审查的例行确认。高质量审批需要提供足够的上下文，以解释拟议操作及其后果。

最佳审批节点应聚焦不可逆或高影响的变更。低风险操作可在既定限制内自动进行。若要求对每一步都确认，工作流的大部分价值便会消失。

维护可能成为最大的隐性成本。企业应用会改变其 API、schema 和权限模型。Blueprint 必须随之演进，同时不能悄然改变其决策含义。

模型替换又引入了一个变量。使用某一模型测试过的工作流，可能在路由变化后呈现不同表现。因此，Barndoor 的治理层除了访问策略外，还需要具备版本感知能力的评估机制。

Diaphora 团队的整合也依然重要。并入式收购可以使团队与既有战略关系保持一致，但产品整合仍需要技术和组织层面的选择。

Barndoor 必须决定 Frags 开发、商业 Blueprints 和现有网关应如何协同。即使底层架构稳健，客户也会注意到管理、文档或调试体验中的不一致。

Syndio 的声明可信地描述了客户面临的问题，但并不能证明组合后的产品已在大规模环境中解决了这一问题。独立案例研究将提供更有力的证据。

因此，Barndoor 收购 Diaphora 应被视为一项技术承诺，而非已完成的验证。它意味着 Barndoor 承诺：治理与工作流执行应属于同一产品。

三个信号将揭示受治理自动化是否有效

接下来的考验在于，Barndoor 能否将具有说服力的控制模型转化为可重复的生产部署。

第一个信号是公开的生产案例研究，并包含可衡量的成果。Barndoor 需要提供来自某一工作流的证据，证明其可跨多个企业系统执行真实操作。

有用的指标包括完成率、安全停止率、人工升级频率和错误操作频率。买方还需要了解工作流的风险等级和测试条件，才能正确解读这些结果。

成功案例将强化 Barndoor 的论点：Blueprints 可以从起草阶段走向实际执行。若只有缺乏运营指标的模糊推荐评价，核心主张仍无法得到验证。

第二个信号是 Frags 与 Barndoor 治理平台之间的技术整合。该公司表示 Diaphora 自动化可以成为受治理的 MCP 工具，但实现细节将决定其价值。

开发者应关注带版本的工作流定义、本地测试、策略模拟、可导出的追踪记录、审批节点和清晰的故障处理。安全团队则需要证据表明，权限会随每个步骤执行，而非只在初始调用时生效。

该集成还应展示当模型、应用或凭证不可用时，Blueprint 会如何响应。在风险更高的工作流中，安全地失败与成功执行同样重要。

一项附带具体文档的透明发布，将增强这笔收购的逻辑基础。反之，若只是松散拼接的产品组合，则会削弱这一逻辑，因为客户仍需分别管理治理与执行。

第三个信号是 Frags 和 FML 能否持续获得外部参与。Barndoor 承诺让该引擎保持开源，使社区活跃度成为衡量这一承诺的可观察指标。

外部提交的 issue、pull request、集成和维护者，将表明 Frags 能够摆脱对私有产品的依赖而继续发展。若代码仓库长期沉寂、主要由内部发布主导，则对平台依赖的防护作用会较弱。

这些信号比又一批 agent 功能更重要。企业已经拥有许多能够调用模型、连接应用的工具；真正较少的是能让这些操作可靠到足以用于日常业务的系统。

Barndoor 对 Diaphora 的收购将治理定位为推动采用的机制，而不是最后一道合规检查。这种转变是可信的，因为员工无法放心地将具有重要影响的工作委托给自己无法理解或约束的系统。

不过，信任仍需要运营层面的证据。组织在从辅助工作转向自主执行之前，应审查工作流边界、失败记录、模型评估和权限范围。

探索类似系统的团队，应从一个范围狭窄、可逆的流程开始。他们可以先通过受控的知识工作流梳理所需信息，再识别哪些步骤确实需要模型判断。

实际的问题不在于 agent 是否能完成一场精致的演示，而在于同一套受治理的流程，在经历数千次运行、输入变化和应用更新后，是否仍能表现得令人满意。

Barndoor 现已承诺回答这一问题。买方应关注首批经过衡量的部署、Frags 集成情况以及开源项目的健康度，再将 Blueprints 视为已被验证的基础设施。