如何将 AI 收益转化为复合基础设施

我过去几年一直在调整我的技术栈，以便一次本地收益能升级整个组合. 这一需求促使我构建了一个共享 AI 能力层、工作流控制平面以及跨本地开发、局域网服务和生产的主机原生操作面. 本文中的名称是我对这些系统的称呼：AI Guard、Agent Gateway 和 System Mesh.

本文讨论的是该技术栈背后的架构. 重点是每一层解决的问题、决定进展的提升规则以及使改进得以持续的运营原则.

在 AI 密集型工作中，最强的结果来自传播. 一个基准结果、缓存胜利、重放改进、lint 规则或部署优化，当每个依赖项目继承它时就会变得持久. 这一设计约束改变了构建的内容. 它更偏好稳定的能力界面而非供应商特定调用. 它更偏好可检查的工作流而非不透明的提示链. 它更偏好使部署、回滚和诊断每次使用都更快的运维契约. 它更偏好通过共享插件、共享技能和共享工具传播的基础改进. 一旦传播成为规则，模型选择就变成更大系统中的一个变量.

我的模型使用取决于细微差别，因为任务携带不同的价值密度. 我将优质推理预算分配给深度规划、架构评审、失败分析和漂移预防. 当输出质量影响重要系统决策时，我接受较长的响应窗口. 我使用面向编码的模型进行长期实施工作，具有强大的 CLI 执行行为和可靠的工具使用。 这就是吞吐量、规划质量和项目拥有技能最重要的通道. 我将重复的有界任务迁移到成本更低的路径，前提是工作流在基准压力下已证明其有效性. 那里确定性 harness、重放和清晰的停止条件解锁了可观的节省. 统治原则是按任务类别进行放置. 工作流拥有模型决策.

我的促销规则是明确的：

当更便宜的路线保持所需质量时，它会被提升. 当成本和质量情况已明确后，更快的路线才重要. 该规则使供应商流失基于可测量的结果，并抵御新颖漂移.

flowchart LR
  A["候选路线"] --> B["基准语料库"]
  B --> C{“质量 >= 基线？”}
  C -->|否| D["留在实验室"]
  C -->|是| E{“成本 <= 当前路线？”}
  E -->|否| F["为高级或专业用途保留"]
  E -->|是| G["推广到共享能力层"]
  G --> H["依赖工作流继承升级"]

那就是将临时 AI 收益转化为复合基础设施的机制.

AI Guard solves a recurring integration problem: projects need AI capabilities, providers and model routes change constantly, and raw per-project integrations create duplicated decision logic, duplicated failure handling, and duplicated spend.

I built AI Guard as the shared capability layer across my projects. Applications call stable capabilities such as structured generation, search, OCR, TTS, image generation, image analysis, and other specialized routes. AI Guard owns the provider-facing layer, cache behavior, pricing awareness, and route promotion.

That design does several useful things at once.

It gives every project one surface for AI work. It captures repeated equivalent requests so benchmark loops and production workloads can reuse prior results. It makes budgeting visible. It keeps route upgrades centralized while application code keeps the same contract.

The compounding effect is straightforward. I benchmark a candidate route once. If it clears the quality bar and improves the economics, I promote it inside AI Guard. Every workflow that depends on that capability inherits the upgrade.

AI Guard 处理能力访问. 我需要第二层来处理带版本控制、重放和发布控制的组合工作流. 我把 Agent Gateway 作为那个工作流控制平面. 项目仓库拥有工作流 YAML。网关处理验证、草稿同步、不可变发布、运行执行、事件、快照、重放点、验证集和步骤缓存. 这解决了一个特定的运营问题. 多步骤 AI 链在中途失败时会累积成本和歧义. 一个不透明的链会强制完全重跑. 一个带步骤边界的版本化运行给我一个精确的干预点. 我的引擎是状态机驱动的. 如果工作流在特定阶段崩溃，我会细化该阶段，从精确边界重放，并保留已经证明有效的上游工作. 那个循环改变了 AI 工作流的经济性和可靠性特征. 通常的路径如下：

发布一个不可变版本，验证通过后.

这就是实验性 AI 链如何变成可检查的基础设施.

当投资组合的形状变得清晰时，我的基础设施层发生了变化. 我曾经花了很长一段时间使用 Coolify 管理的 Docker 车道作为默认的运营模式。 这在早期阶段很有效，边界快速移动时也很合适. 随着服务图稳定，我想为符合主机本地处理的服务提供更快、更清晰的操作员界面. 我想在本地开发、我的 LAN 服务主机和生产环境之间有一个统一的合同. 我想要诊断能够呈现代理或操作员真正需要的信号. 我想让部署、环境渲染、路由和回滚成为一流、可读的操作. 我把 System Mesh 作为共享服务管理合同来实现这一目的，通过环境特定的清单、CLI 和技能来实现. 在这个堆栈中，dev 拥有本地运行时操作，mint 拥有 LAN 主机，prod 拥有生产环境。 共享合同保持词汇一致，同时每个环境应用自己的策略. 这一转变将常见的部署路径从大约三分钟缩短到大约三十秒. 更大的收益是架构层面。每个符合主机本地车道的服务都继承更快的部署、更尖锐的诊断和更明确的运营模型. 我仍然在依赖关系配置合理的地方使用容器. 重要的系统依赖仍然是保留 Docker 执行的良好候选者 指导原则是按服务约束进行执行模式放置.

我使用实验室来决定哪些值得晋升. 一个实验室拥有基准语料库、评分规则、挑战者集合和通过标准. 这为我提供了一种干净的方法，将探索性工作与运营路线分离. 高价值规划和架构仍可使用高级推理模型. 当任务受限、工作流可读且结果可评估时，低成本路线接管. 翻译维护是一个很好的例子. 我运行受限的代理流程，爬取 i18n JSON，检测缺失或弱翻译，并在受限的步骤预算内修补文件。 该任务可以在低成本 OSS 类路线运行，具有强大的吞吐量和显著的成本降低，因为工作流已被基准化、可重放且易于评分. 实验室让市场快速移动，而生产代码则基于已验证的证据进行迭代.

最大的长期收益在基础层面显现. 我使用项目技能，使代理能够在本地系统、生产系统和共享服务中操作，并从一开始就拥有即时上下文. 我将 linting 作为持久化机制：当运行时失败揭示出应当被静态预防的模式时，我一次性编码该防护措施，使整个组合继承它. 我还维护一个共享基础，拥有超过六十个插件，覆盖重复出现的应用形态. 身份验证、SEO、电子邮件、工作流集成和操作员人体工学在中心得到改进，然后向外传播. 这就是理论在日常工作中变得可见的地方. 回归次数减少. 修复提前分发. 速度提升，因为以往的经验已被保留.

我指示 AI 从本文所述的方法中提取操作原则：