生产工作流中的 AI/ML 推理集成

大多数企业 AI 项目在演示到生产的过渡中消亡。团队构建了一个使用 GPT-4 分类支持工单、总结法律文件或生成营销文案的概念验证。演示有效。领导层兴奋了。然后项目因为演示从未需要回答的问题而停滞数月：数据从哪里来？输出发到哪里？谁审批 AI 的决策？模型产生幻觉怎么办？如何审计它做了什么？如何防止它访问不该看的数据？如何阻止它将敏感信息发到错误的地方？

这些不是假设性的担忧。95% 的企业生成式 AI 试点未能产生财务回报，原因不是技术不行。模型是有能力的。失败在于基础设施：将 AI 推理可靠地集成到需要它运作的实际业务工作流中，同时具备生产系统所需的安全控制、错误处理和审计追踪。

典型的企业应对是构建定制集成层。一个工程团队花数月时间将 AI 模型连接到数据源、构建流水线、添加认证、实现日志、创建审批工作流并添加安全检查。等到集成"生产就绪"时，原始模型已被更新的模型取代，业务需求已经转变，团队需要从头再来。

Triggerfish 的解决方案

Triggerfish 通过将 AI 推理变成工作流引擎的一等公民步骤来消除集成差距。该步骤受与系统中其他所有操作相同的安全执行、审计日志和分类控制管理。Triggerfish 工作流中的 LLM 子代理步骤不是后加的组件——它是与 HTTP 调用或数据库查询具有相同策略钩子、血缘追踪和写入降级防止的原生操作。

AI 作为工作流步骤，而非独立系统

在工作流 DSL 中，LLM 推理步骤用 call: triggerfish:llm 定义。任务描述用自然语言告诉子代理该做什么。子代理可以访问 Triggerfish 中注册的每个工具：可以搜索网络、通过 MCP 工具查询数据库、读取文档、浏览网站并使用跨会话记忆。步骤完成后，其输出直接进入工作流的下一步。

这意味着没有需要集成的独立"AI 系统"。推理发生在工作流内部，使用与其他一切相同的凭据、相同的数据连接和相同的安全执行。工程团队不需要构建定制集成层，因为集成层已经存在。

无需定制工程的安全性

将 AI 工作流生产化中最耗时的部分不是 AI 本身，而是安全和合规工作。模型可以看哪些数据？输出可以发送到哪里？如何防止泄露敏感信息？如何记录一切以供审计？

在 Triggerfish 中，这些问题由平台架构而非每个项目的工程来回答。分类系统在每个边界追踪数据敏感度。模型访问机密数据时会话 taint 升级。写入降级防止阻止输出流向分类低于会话 taint 级别的频道。每次工具调用、每次数据访问和每次输出决策都有完整血缘记录。

读取客户记录（CONFIDENTIAL）并生成摘要的 AI 工作流，无法将该摘要发送到公开的 Slack 频道。这不是由模型可能忽略的提示指令来执行，而是由模型看不到、无法修改且无法绕过的 PRE_OUTPUT 钩子中的确定性代码来执行。策略钩子在 LLM 层之下运行。LLM 发出操作请求，策略层决定是否允许。超时等同于拒绝。从模型到外部世界不存在不经过执行的路径。

从第一天就存在的审计追踪

Triggerfish 工作流中的每个 AI 决策都自动生成血缘记录。血缘追踪模型访问的数据、数据所携带的分类级别、应用的转换以及输出被发送的位置。这不是需要启用或配置的日志功能——这是平台的结构属性。每个数据元素从创建到每次转换再到最终目的地都携带来源元数据。

对于受监管的行业，这意味着 AI 工作流的合规证据从第一天起就存在。审计员可以追踪任何 AI 生成的输出，通过完整链条：哪个模型生成了它、基于什么数据、模型在推理过程中使用了哪些工具、每个步骤适用的分类级别，以及是否发生了任何策略执行操作。这种证据收集是自动的，因为它内置在执行钩子中，而不是作为报告层添加上去的。

无需重新架构的模型灵活性

Triggerfish 通过 LlmProvider 接口支持多个 LLM 提供商：Anthropic、OpenAI、Google、通过 Ollama 的本地模型，以及通过 OpenRouter 的任何路由模型。提供商选择可以按代理配置，带有自动故障转移。当更好的模型可用或提供商更改定价时，切换在配置层面发生，无需触及工作流定义。

这直接解决了"项目在发布前就过时"的问题。工作流定义描述 AI 应该做什么，而不是哪个模型来做。从 GPT-4 切换到 Claude 再到微调的本地模型，只需更改一个配置值。工作流、安全控制、审计追踪和集成点都保持完全不变。

Cron、Webhook 和事件驱动执行

按计划运行或响应事件的 AI 工作流不需要人工提示。调度器支持用于定期工作流的五字段 cron 表达式，以及用于事件驱动触发器的 webhook 端点。日报生成工作流在早上 6 点运行。文档分类工作流在新文件通过 webhook 到达时触发。情感分析工作流在每个新支持工单时触发。

每次计划或事件触发的执行都会产生一个带有全新 taint 的隔离会话。工作流在自己的安全上下文中运行，独立于任何交互式会话。如果 cron 触发的工作流访问了 CONFIDENTIAL 数据，只有该执行的历史被分类为 CONFIDENTIAL。以 PUBLIC 分类运行的其他计划工作流不受影响。

错误处理与人工审核

生产 AI 工作流需要优雅地处理失败。工作流 DSL 支持用于显式错误条件的 raise 以及通过任务定义中的错误处理实现的 try/catch 语义。当 LLM 子代理产生低置信度输出或遇到无法处理的情况时，工作流可以路由到人工审批队列、通过通知服务发送通知，或采取备用操作。

通知服务以优先级和去重方式向所有连接的频道传递告警。如果 AI 生成的合同修改在发送之前需要人工审批，审批请求可以出现在审批者所在的 Slack、WhatsApp、邮件或任何其他地方。工作流暂停直到审批通过，然后从暂停的地方继续。

实际应用案例

法务部门想要自动化合同审查。传统方式：六个月的定制开发，构建从上传合同中提取条款、分类风险级别、标记非标准条款并为审查律师生成摘要的流水线。该项目需要专职工程团队、定制安全审查、合规批准以及持续维护。

使用 Triggerfish，工作流定义只需一天编写。上传触发 webhook。LLM 子代理读取合同、提取关键条款、分类风险级别并识别非标准条款。验证步骤将提取结果与存储在记忆中的律所条款库进行对比。摘要被路由到指定律师的通知频道。由于合同包含客户特权信息，整个流水线以 RESTRICTED 分类运行，写入降级防止确保合同数据不会泄露到 RESTRICTED 以下的频道。

当律所切换 LLM 提供商（因为新模型更好地处理法律语言，或者当前提供商涨价），变更只是配置中的一行。工作流定义、安全控制、审计追踪和通知路由全部继续工作，无需修改。当律所向其风险框架添加新条款类型时，LLM 子代理无需重写提取规则即可处理，因为它读取的是含义而非模式。

合规团队从第一天起就获得完整的审计追踪：每份处理过的合同、每个提取的条款、每个分配的风险分类、每次发送的通知以及每次律师审批记录，都带有回溯到源文档的完整血缘。原本需要数周定制报告工作的证据收集，作为平台的结构属性自动存在。