带判断能力的跨系统编排

一个典型的采购到付款工作流涉及十几个系统。采购申请在一个平台发起，被路由到另一个系统的审批链，触发第三个系统的供应商查询，在第四个系统创建采购订单，在第五个系统启动收货流程，在第六个系统匹配发票，在第七个系统安排付款，并在第八个系统记录一切。每个系统都有自己的 API、自己的更新节奏、自己的认证模型和自己的故障模式。

传统自动化用刚性流水线处理这些问题。第一步调用 API A，解析响应，将字段传给第二步，第二步调用 API B。在正常情况下运行良好。但一旦供应商记录格式与预期略有不同，审批以流水线未设计的状态码返回，或 API 更新中出现了新的必填字段，整个链条就会断裂，而且没有人知道，直到几天后某个下游流程开始报错。

问题的根源不是技术脆弱性，而是真实的业务流程需要判断力。这张发票的差异应该上报还是自动处理？这个供应商的延误模式是否需要重新审视合同？这个审批请求紧急到需要跳过标准路由吗？这些决策目前存在于人脑中，因此自动化只能处理顺畅路径。

Triggerfish 的解决方案

Triggerfish 的工作流引擎执行基于 YAML 的工作流定义，在单个流水线中混合确定性自动化和 AI 推理。工作流中的每个步骤都通过与所有 Triggerfish 操作相同的安全执行层，因此无论涉及多少系统，分类追踪和审计追踪都贯穿整个链条。

确定性工作用确定性步骤

当工作流步骤的输入和输出都是已知的，它就作为标准 HTTP 调用、Shell 命令或 MCP 工具调用执行。没有 LLM 介入，没有延迟惩罚，没有推理成本。工作流引擎支持用于 REST API 的 call: http、用于任何已连接 MCP 服务器的 call: triggerfish:mcp，以及用于命令行工具的 run: shell。对于可预测的工作，传统自动化是正确的方式，这些步骤就像传统自动化一样精确执行。

需要判断时的 LLM 子代理

当工作流步骤需要情境推理时，引擎使用 call: triggerfish:llm 生成一个真正的 LLM 子代理会话。这不是单次提示/响应。子代理可以访问 Triggerfish 中注册的每一个工具，包括网络搜索、记忆、浏览器自动化以及所有已连接的集成。它可以读取文档、查询数据库、比较记录，并基于所发现的一切做出决策。

子代理的输出直接输入工作流的下一步。如果它在推理过程中访问了机密数据，会话 taint 会自动升级并传播回父工作流。工作流引擎会追踪这一点——一个从 PUBLIC 开始但在判断调用中触及了 CONFIDENTIAL 数据的工作流，其整个执行历史会以 CONFIDENTIAL 级别存储。较低分类的会话甚至看不到该工作流曾经运行过。

基于真实上下文的条件分支

工作流 DSL 支持用于条件路由的 switch 块、用于批处理的 for 循环，以及用于更新工作流状态的 set 操作。结合能够评估复杂条件的 LLM 子代理步骤，这意味着工作流可以基于真实的业务上下文而非仅仅字段值来分支。

采购工作流可以根据子代理对供应商风险的评估采取不同路由。入职工作流可以跳过对特定角色不相关的步骤。事件响应工作流可以根据子代理的根本原因分析升级到不同的团队。分支逻辑存在于工作流定义中，但决策输入来自 AI 推理。

系统变更时的自愈能力

当确定性步骤因为 API 改变了响应格式或系统返回了意外错误而失败时，工作流不会就此停止。引擎可以将失败的步骤委托给 LLM 子代理来读取错误、检查响应并尝试替代方案。添加了新必填字段的 API 由读取错误消息并调整请求的子代理来处理。更改了认证流程的系统由浏览器自动化工具来导航。

这并不意味着每次故障都能神奇地解决。但这意味着工作流会优雅降级而不是悄然失败。子代理要么找到前进的路，要么产生清晰的解释说明发生了什么变化以及为什么需要人工干预，而不是埋在没人查看的日志文件里的神秘错误码。

贯穿整个链条的安全性

Triggerfish 工作流中的每个步骤都通过与任何直接工具调用相同的策略执行钩子。PRE_TOOL_CALL 在执行前验证权限并检查速率限制。POST_TOOL_RESPONSE 对返回数据进行分类并更新会话 taint。PRE_OUTPUT 确保任何数据不会以高于目标允许的分类级别离开系统。

这意味着一个从 CRM（CONFIDENTIAL）读取数据、通过 LLM 处理，并将摘要发送到 Slack 的工作流，不会意外地将机密细节泄露到公开频道。写入降级防止规则在 PRE_OUTPUT 钩子处捕获这种情况，无论数据经过多少中间步骤。分类标签随数据在整个工作流中传播。

工作流定义本身可以设置 classification_ceiling，防止工作流接触超过指定级别的数据。分类为 INTERNAL 的每周摘要工作流，即使拥有相应凭据也无法访问 CONFIDENTIAL 数据。这个上限由代码强制执行，而不是寄希望于 LLM 遵守提示指令。

Cron 与 Webhook 触发器

工作流不需要人工手动启动。调度器支持用于定期工作流的基于 cron 的触发器，以及用于事件驱动执行的 webhook 触发器。早报工作流在早上 7 点运行。当 GitHub 发送 webhook 时，PR 审查工作流启动。当共享驱动器中出现新文件时，发票处理工作流触发。

Webhook 事件带有自己的分类级别。私有仓库的 GitHub webhook 会根据安全配置中的域名分类映射自动分类为 CONFIDENTIAL。工作流继承该分类，所有下游执行都会适用相应的限制。

实际应用案例

一家在 NetSuite、Coupa、DocuSign 和 Slack 上运行采购到付款流程的中型企业，定义了一个处理完整周期的 Triggerfish 工作流。确定性步骤处理创建采购订单、路由审批和匹配发票的 API 调用。LLM 子代理步骤处理例外情况：行项目与采购订单不匹配的发票，以意外格式提交文件的供应商，需要申请人历史背景的审批请求。

工作流运行在自托管的 Triggerfish 实例上。数据不会离开公司的基础设施。分类系统确保 NetSuite 的财务数据保持在 CONFIDENTIAL 级别，无法发送到分类为 INTERNAL 的 Slack 频道。审计追踪记录了 LLM 子代理做出的每个决策、调用的每个工具以及访问的每条数据，并带有完整的血缘追踪以供合规审查。

当 Coupa 更新了 API 并更改了字段名称，工作流的确定性 HTTP 步骤失败了。引擎委托给一个子代理，它读取错误、识别已更改的字段，并用正确的参数重试。工作流无需人工干预即完成，该事件被记录下来，工程师可以更新工作流定义以处理新格式。