把AI Agent真正“发货”：一次用Dagger构建工程级智能体的实战

这不是一场关于“AI 很强”的演示，而是一场关于如何把 AI Agent 安全、可复现、可维护地交付到真实工程里的工作坊。Kyle Penfound 和 Jeremy Adams 用 Dagger 从零搭起一个能跑在本地、CI 和 GitHub Actions 里的 Agent，展示了工程化智能体的完整路径。

为什么大多数 AI Agent 死在 Demo：工程一致性才是关键

这场工作坊一开始就点出了一个行业痛点：AI Agent 的 demo 往往很惊艳，但一旦进入真实工程环境，就会因为环境不一致、权限失控、流程不可复现而失效。这也是 Kyle 和 Jeremy 强调 Dagger 的第一个原因——“it runs the same everywhere”。Dagger 的核心价值不是又一个容器工具，而是把整个软件工程流程（构建、测试、发布，甚至 AI Agent 的运行）抽象成可编排、可复现的代码。

他们明确区分了 Dagger 和 Docker 的角色。Docker 解决的是“如何封装一个运行时环境”，而 Dagger 解决的是“如何描述一个完整的软件工程工作流”。Dagger 本身基于容器运行，但它提供的是一个统一 API，让同一套逻辑可以在本地、CI 或云端无差别执行。这一点对 AI Agent 尤其重要，因为 Agent 往往需要调用代码、读写文件、运行测试，而这些操作最怕“在我电脑上是好的”。

Jeremy 在介绍中反复强调，Dagger 是为软件工程工作流而生的，而 AI Agent 只是其中一个新出现、但极其苛刻的使用场景。Agent 不只是调用模型，它还要“像工程师一样”在代码库里行动。这就要求我们对它的能力边界、运行环境和输入输出有极强的控制力，而不是把一个大模型直接丢进仓库里祈祷它别出事。

从 Hello Dagger 到模块化思维：Agent 不是魔法，是积木

在进入 AI Agent 之前，工作坊先花了不少时间打基础：创建容器、理解 Dagger 的 building blocks。Kyle 用一个非常工程化的比喻来解释这一点——就像产品经理在发布前要反复拆解需求，工程里的每一步也应该是可组合的模块，而不是一团脚本。

他们现场使用的是 Python，并从一个“Hello Dagger template”开始，把项目 clone 到本地，通过 Dagger 的可视化能力展示每一步在干什么。这种可视化不是为了炫技，而是为了让开发者真正理解：当前这个函数，依赖了哪些输入，产出了什么结果。这为后面引入 Agent 打下了心理模型。

接下来是创建 Dagger module。模块里定义的是函数，而这些函数最终都会通过 Dagger 的统一 API 暴露出来。Jeremy 特别强调，“one API under the hood”意味着无论你是在本地调用，还是在 CI 里跑，行为都是一致的。这一点在后面把 Agent 接入 GitHub Actions 时变得至关重要。

一个容易被忽略的细节是：他们并没有急着谈模型或提示词，而是先把工程结构搭好。这背后的方法论很清晰——AI Agent 不是一个黑盒大脑，而是被装进了一个严格定义的‘机器人身体’里。只有身体结构稳定，大脑才有发挥空间。

把大脑装进机器人：如何给 AI Agent 恰到好处的能力

真正进入 Agent 部分时，Kyle 用了一句非常形象的话：“we’re putting the brain into the robot body”。这个“身体”，就是 Dagger module；这个“大脑”，才是大语言模型。工作坊展示的是如何把一个 Agent 加进现有项目，而不是为 Agent 单独造一个玩具仓库。

关键决策出现在“权限”这一层。他们明确提出一个张力：在灵活性和可靠性之间取平衡。Agent 能做的事情，必须通过工具显式声明，而不是默认给它整个仓库的控制权。通过 Dagger，你可以精确地决定 Agent 能调用哪些函数、访问哪些文件、是否能运行测试。这种约束不是限制智能，而是防止不可控行为。

在代码层面，Agent 的核心函数被命名为 develop。它不是一个抽象概念，而是一个可运行、可测试的函数。组成 Agent 的要素也被拆得很清楚：工具、上下文、以及 prompt.markdown。Kyle 直接指出，prompt 文件不是随便写几句指令，而是整个 Agent 行为的“契约”。

在这里，他们抛出了一个金句，被称为“the most important line of the workshop”。虽然语气轻松，但意思非常重：如果你无法清楚解释你的 Agent 在做什么、为什么这么做，那它迟早会在生产环境里出问题。

从本地到 GitHub Actions：一个 Agent 的完整生命周期

工作坊后半段展示了一个非常完整的闭环：在本地开发 Agent、观察它如何调用工具、获得所需的可视化，然后把同一个 Agent 放进 GitHub Actions 里运行。这里的关键不是“能不能跑”，而是“有没有额外成本”。答案是几乎没有。

他们创建了一个 GitHub issue module，并配置了对应的 GitHub Actions workflow。当一个新 issue 出现时，Agent 会被触发，执行 develop 函数，跑测试，并最终提交一个 PR。在演示中，Actions 页面清楚地显示了执行过程，甚至能看到 Agent 没有修改测试文件这一细节。

有意思的是，当 PR 打开时，大家看到的不是一段神秘的 AI 输出，而是一个完全符合工程规范的变更。这也是 Dagger 被反复强调的原因：Agent 的每一步行为，都是在一个可审计、可复现的环境里完成的。

在最后，Kyle 还展示了可以直接和连接的大语言模型聊天，并解释了为什么要把这种能力做成 Dagger 的一等原语。这不是为了方便玩模型，而是为了让模型成为工程系统里一个受控的组件，而不是漂浮在系统之外的“神经中枢”。

总结

这场《Ship Agents that Ship》最有价值的地方，并不在于展示了一个多聪明的 AI Agent，而在于它回答了一个更难的问题：如何把 Agent 当作软件工程的一部分来交付。Dagger 提供的不是魔法，而是一种纪律——统一环境、明确边界、模块化思维。对任何想把 AI Agent 推进生产环境的团队来说，这种工程视角，可能比模型本身更重要。

关键词： Dagger， AI Agent， 软件工程工作流， 提示工程， 大语言模型

事实核查备注： 视频标题：Ship Agents that Ship： A Hands-On Workshop；演讲者：Kyle Penfound， Jeremy Adams；核心工具：Dagger；编程语言示例：Python；关键概念：Dagger module、develop function、prompt.markdown、GitHub Actions；核心观点引用："it runs the same everywhere"、"one API under the hood"、"we’re putting the brain into the robot body"。