12-Factor Agents：如何把不可靠的智能体，做成工程化软件

Dex Horthy在这场演讲中提出“12-Factor Agents”方法论，试图解决一个现实问题：为什么我们能快速做出AI Agent Demo，却很难把它们变成可靠的软件系统。核心不是模型多强，而是工程边界、控制流与上下文的掌控。

从“我也在造Agent”开始，但问题很快暴露

演讲一开始，Dex Horthy先抛出一个问题：“谁在构建Agent？谁已经构建了10个以上？100个呢？”现场少数人举手的反差，本身就是一个信号——Agent看起来门槛很低，但真正规模化的人并不多。Dex直言，大多数人都经历过同一段旅程：最初的Agent令人兴奋，几秒钟就能跑起来，但很快就变得不可控。他特别强调一句看似扫兴却极其重要的话：“Not every problem needs an agent.” 并不是所有问题都值得用Agent解决。很多失败的项目，并不是模型不行，而是一开始就选错了问题形态。这一判断，为后面所有“因子”奠定了工程理性的基调。

12-Factor Agents：不是炫技，而是追求可靠性

Dex提出“12-Factor Agents”的背景，并不是学术追求，而是工程痛点：如何在“高可靠性”和“快速迭代”之间取得平衡。他明确指出，这套思路的灵感，来自早年云原生应用的工程经验——那些“10年前就能在云上跑”的系统，靠的不是魔法，而是清晰的约束。他说自己想做的，并不是让大家记住12条规则，而是“带走其中一条，今天就能用进你的应用”。这也解释了为什么他反复强调：Agent本质上是软件，而不是某种全新物种。你依然需要面对状态、失败、回放、调试这些老问题，只是现在它们被语言模型放大了。

工具、控制流与上下文：真正的复杂性来源

在多个“因子”中，Dex花了大量时间拆解三个容易被误解的点。第一是工具（Tools）。他直接引用“Go To Considered Harmful”的梗，强调“工具没什么特别的，本质就是JSON和代码”。问题不在工具，而在你是否把控制权交给了模型。于是引出第二点：必须“拥有你的控制流”。无论是循环、分支、重试，还是失败恢复，都应该由系统决定，而不是让模型自由发挥。第三点则更具争议性——上下文构建。Dex坦言这是一个“standalone factor”，因为大家都想把一切塞进上下文，但真正可靠的Agent，必须明确谁在什么时候、以什么规则构建上下文，否则你根本无法调试或复现行为。

小而专注的Agent，而不是全能助理

在后半段，Dex反复强调一个反直觉结论：更强的Agent，往往更小。他提出应当构建“small， focused agents”，每个Agent只解决一类明确问题，而不是模仿一个无所不知的助手。这背后的工程原因是状态管理与组合复杂度。他用“stateless reducers”的梗图说明：当Agent尽量无状态、行为可组合时，系统才具备可维护性。即便在不同交互形态中——无论是Discord、SMS还是其他渠道——这种小Agent模式都在迅速扩散。与其追求一个看似聪明却不可预测的系统，不如构建一组行为清晰、边界明确的Agent网络。

总结

Dex Horthy在总结时说得很直白：“Agents are software.” 这句话既是提醒，也是解放。你不需要把Agent神秘化，而是要用成熟的软件工程思维去约束它们。12-Factor Agents并不是要限制创造力，而是让你在可控的前提下更快迭代。对正在构建Agent系统的人来说，最大的启发也许不是某一条具体因子，而是这套态度：把可靠性设计进去，而不是事后补救。

关键词： 12-Factor Agents， AI Agent， LLM应用， 控制流， 上下文管理

事实核查备注： 演讲者：Dex Horthy；视频标题：12-Factor Agents： Patterns of reliable LLM applications；核心原话包括："Not every problem needs an agent"、"Tools are just JSON and code"、"Agents are software"；关键技术概念：控制流（control flow）、上下文构建（context building）、小而专注的Agent（small focused agents）、stateless reducers。