YC创业者推12因素智能体法则弃用开源框架直接控核心

AI技术投降派

生产级AI Agent难以落地源于过度依赖框架黑箱，开发者必须回归朴素软件工程并自主掌控提示词与状态管理。

AI-assisted summary of 为什么你的 AI Agent 到不了生产级？25k 星开源方法论说透了 — original source. Check the original for full context.

Source published: 2026-08-20

Detailed notes

## Background 该内容由 Bilibili UP 主“AI技术投降派”于 2026 年 8 月 20 日发布。视频围绕 HumanLayer 创始人 Dex Horthy 提出的开源方法论《12-Factor Agents（十二因素智能体）》展开，旨在解答为什么许多基于开源框架搭建的 AI Agent 难以交付给生产级客户，并系统性拆解如何用朴素的软件工程原则构建可靠的生产级 AI 软件。

## TL;DR 很多开发者在用开源框架构建 AI Agent 时，常在达到 70%~80% 完成度后陷入“死亡谷”，面临输出不稳定、上下文爆满及调试困难等生产瓶颈。演讲者指出 Agent 的本质其实是一个由“大模型决策-确定性代码执行-结果追加上下文”组成的简单循环，顶级开发者大多选择抛弃封装黑箱的复杂框架并自己实现。通过“掌控三件套”、“结构与生命周期”、“将人类当工具调用”以及“规模化五原则”（如将 Agent 做成无状态规约器），开发者能够将 AI 带来的不确定性纳入严密的传统工程控制之下，从而打造出真正具备抗造性的生产线系统。

## Atmosphere & style 整个分享充满了一种冷静、务实且反骨的“工程师清醒感”。叙述摒弃了对 AI 技术的盲目崇拜与浮躁炒作，语气接地气且充满警醒，直击开发者给黑箱 Prompt“擦屁股”的切肤之痛。在揭示框架局限性与拆解十二条原则时，逻辑严密而干脆利落，将前端与云原生的成熟哲学融会贯通，给人一种剥离技术神话、重返朴素工程本质的踏实与通透感。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=0s) 针对 AI Agent 在演示阶段表现亮眼、部署到生产环境即陷入失控的行业困境，开源项目《12-Factor Agents》梳理了一套指导生产级交付的工程原则。 - [01:02](https://www.bilibili.com/video/BV1dEMS6QExa?t=62s) 《12-Factor Agents》致敬了 2011 年 Heroku 提出的《12-Factor App》，由 HumanLayer 创始人 Dex Horthy 发起。 - [02:34](https://www.bilibili.com/video/BV1dEMS6QExa?t=154s) Agent 开发普遍存在“八成死亡谷”现象：框架能帮助开发者快速搭建 80% 的功能，但要突破剩余 20% 的生产级天花板，往往需要反向工程框架内部流程甚至推倒重来。 - [03:52](https://www.bilibili.com/video/BV1dEMS6QExa?t=232s) 调查显示绝大多数真正做出顶级 Agent 产品的团队根本不使用开源 Agent 框架，而是自研底层代码。 - [03:52](https://www.bilibili.com/video/BV1dEMS6QExa?t=232s) 好的 Agent 本质上主要就是软件，依靠的是朴素的软件工程而非玄学 Prompt 或 Agent 框架。 - [05:13](https://www.bilibili.com/video/BV1dEMS6QExa?t=313s) Agent 的本质是一个极简的执行循环：大模型决策输出工具调用 -> 确定性代码执行 -> 执行结果追加回上下文。 - [06:28](https://www.bilibili.com/video/BV1dEMS6QExa?t=388s) “掌控三件套”（原则 1-3）：开发者必须精准实现自然语言到工具调用的转换，并显式掌控提示词（Prompts）与上下文窗口（Context Window），放弃控制权等于放弃质量。 - [07:49](https://www.bilibili.com/video/BV1dEMS6QExa?t=469s) “结构与生命周期”（原则 4-6）：将工具调用视为结构化输出，统一管理 Agent 执行状态与业务状态，并为长时运行任务提供简单的启动、暂停与恢复接口。 - [09:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=540s) “把人类当作工具调用”（原则 7）：面对高风险操作时，将询问人类（Human-in-the-loop）设计为标准的工具调用，平衡系统的自动化能力与安全性。 - [10:30](https://www.bilibili.com/video/BV1dEMS6QExa?t=630s) “规模化五原则”（原则 8-12）：掌控控制流重试逻辑、提炼压缩错误回传至上下文、保持 Agent 小而专注、支持随处触发多渠道交互，以及将 Agent 架构设计为无状态规约器（Stateless Reducer）。 - [12:23](https://www.bilibili.com/video/BV1dEMS6QExa?t=743s) 原则 12 借鉴 React/Redux 思想，将 Agent 打造为无状态规约器，自身不持有内部状态，从而大幅提升系统的可测试性与扩展能力。 - [12:23](https://www.bilibili.com/video/BV1dEMS6QExa?t=743s) 生产级 AI 软件的研发应当提取小而模块化的概念融入已有成熟系统，底层大模型虽在增强，但朴素的工程纪律才是解决软件复杂度的关键。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=0s) AI Agent 难以迈向生产级的困境与《12-Factor Agents》的诞生

开发者在构建 AI Agent 时普遍存在一种痛点：使用现成的 Agent 框架搭建演示（Demo）时效果惊艳，全场赞叹，但一旦真正部署给生产客户使用，系统便开始失控。典型症状包括输出不稳定、工具调用（Tool Calling）频繁出错、上下文窗口（Context Window）莫名其妙被塞爆，开发者往往需要花费比写业务代码多得多的时间去调优提示词（Prompt），最终沦为给大模型这个“黑箱”擦屁股。这并非个别现象，而是困扰全行业的瓶颈。

为了解决这一难题，GitHub 上出现了一个获得 2.5 万颗星（25k Stars）的开源项目——**12-Factor Agents（十二因素智能体）**。该项目致力于总结出一套工程化原则，指导开发者构建出真正能交付给生产环境客户的 AI 软件。

* **致敬经典：** 该方法论直接致敬了 2011 年 Heroku 工程师 Adam Wiggins 撰写的经典文档《12-Factor App（十二因素应用）》。当年《12-Factor App》用 12 条原则定义了现代云原生应用，为一整代开发者提供了共同语言；如今《12-Factor Agents》则针对 LLM 应用，尝试回答“什么样的 AI Agent 才算真正达到生产级”。 * **作者背景：** 该项目作者 Dex Horthy 曾在 Replicated 工作 7 年，帮助大量团队将产品改造为跑在 Kubernetes 上的云原生架构，拥有扎实的容器编排、产品及市场经验。2023 年，他创立了拿到 Y Combinator (YC) 投资的初创公司 HumanLayer。

---

[02:34](https://www.bilibili.com/video/BV1dEMS6QExa?t=154s) Agent 开发的“八成死亡谷”与核心洞察

在对超过 100 位尝试将产品 Agent 化的创业者进行调研后，Dex Horthy 总结出了一个极具代表性的“Agent 开发死亡谷”模式。绝大多数团队的开发路径都会经历相同的七个步骤：

1. 决定做一个 AI Agent； 2. 做产品设计，明确要解决的问题； 3. 为了赶进度，随手抓一个现成的 Agent 开源框架； 4. 极快地将产品做到 70%~80% 的完成度； 5. 发现这 80% 的完成度对于直接面向客户的生产级功能而言远远不够； 6. 意识到要想突破剩下 20% 的天花板，必须反向工程（Reverse Engineer）框架内部的 Prompt 流程与状态管理； 7. 最终忍无可忍，选择推倒重来。

> "框架能帮你快速起跑，却把你困在八成的天花板下面。"

Dex 发现，无论是 YC 内部还是外部，真正做出了顶级 Agent 产品的创始人，绝大多数**根本不用开源 Agent 框架**，而是选择自己动手从底层写一套。这直接暴露了现成框架在生产环境中的乏力。

由此，Dex 抛出了一个极其反直觉的断言：市面上绝大多数标榜为 AI Agent 的产品，本质上**并不那么 Agentic**。它们的主体依然是确定性（Deterministic）的代码，仅仅是在少数关键节点点缀了大模型调用。

同时，好的 Agent 绝非“给一段 Prompt、给一袋工具，就让大模型自己死循环直到完成目标”。**好的 Agent，说到底主要就是软件。** 构建可靠的 AI 应用，靠的不玄学的 Prompt，也不是少一点动画的框架，而是最朴素的软件工程。

---

[05:13](https://www.bilibili.com/video/BV1dEMS6QExa?t=313s) Agent 的本质：一个极简的执行循环

Dex Horthy 给 Agent 下了一个非常清醒且剥离神话色彩的定义：**Agent 的本质就是一个循环（Loop）。** 这个循环由三个固定步骤组成：

1. **大模型决策：** LLM 根据当前的上下文，决定下一步做什么，并输出结构化的工具调用（Tool Call）。 2. **确定性代码执行：** 由一段确定性的传统代码，真正去执行该工具调用。 3. **结果追加上下文：** 将工具执行的真实结果追加（Append）回 LLM 的上下文窗口中。

上述三步不断重复，直到 LLM 判断任务完成。

然而，这个看似优雅的循环在实际运行中极易崩溃——它会犯错、跑偏、塞爆上下文、或在不该停的时候停止。为了将这个不靠谱的“玩具循环”工程化为抗造的生产级系统，12-Factor Agents 将其拆解为十二条工程原则。

---

[06:28](https://www.bilibili.com/video/BV1dEMS6QExa?t=388s) 掌控三件套（原则 1 - 3）

第一组原则围绕一个核心概念——**“控”**。开发者放弃对系统的控制权，就等于放弃产品质量。

* **原则 1：自然语言转工具调用（Natural Language to Tool Calls）** Agent 的入口是用户的自然语言（人话），但后端系统需要结构化指令。系统必须拥有一套稳定可靠的机制，将非结构化文本精确翻译为结构化工具调用。 * **原则 2：掌控你的提示词（Own Your Prompts）** 直接针对封装 Prompt 的黑箱框架。当框架把 Prompt 隐藏起来时，开发者在需要精调时根本触碰不到。开发者必须能完全看见并自由修改每一个 Prompt。 * **原则 3：掌控你的上下文窗口（Own Your Context Window）** 上下文窗口是 LLM 的内存/短期记忆，也是最被低估的一环。哪些信息塞入、哪些清理、何时进行压缩（Compression），必须由开发者主动显式管理，决不能甩手交给框架去黑盒处理。

---

[07:49](https://www.bilibili.com/video/BV1dEMS6QExa?t=469s) 结构与生命周期（原则 4 - 6）

第二组原则关注 Agent 系统的架构逻辑与状态生命周期管理：

* **原则 4：工具就是结构化输出（Tools are Structured Outputs）** 不要把 Tool Call 想得过于神秘，其本质就是让大模型输出符合特定 Schema 的结构化数据。明确这一点后，开发者便可以用同一套工程范式统一处理工具、执行结果及报错。 * **原则 5：统一执行状态与业务状态（Unify Execution and Business State）** Agent 运行产生的执行状态（如执行到哪一步、调用了哪些工具）不应单独搞一套 Agent 专属数据库，而应与业务数据放在同一个存储层统一管理，避免系统出现多头管理、顾此失彼的情况。 * **原则 6：用简单的接口实现启动、暂停与恢复（Start, Pause, and Resume with Simple Interfaces）** Agent 往往属于长时运行任务（Long-running Tasks），不能无休止地占用系统资源。系统必须具备随时将 Agent 挂起、持久化当前状态并在满足条件后恢复运行的能力。这是 Agent 迈向生产线的关键。

---

[09:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=540s) 把人类当作工具调用（原则 7）

**原则 7：用工具调用来联系人类（Contact Humans via Tool Calls）** 是整个十二条原则中最具特色的一条，也是 Dex 创立 HumanLayer 的核心出发点。

Agent 在执行删库、发送邮件、资金支付等高风险操作时，完全自主执行极易酿成灾难，但每一步都由人工盯盘又失去了自动化的价值。Dex 提出了一个极其巧妙的解法：**将“询问人类”本身设计成一种标准的 Tool Call。**

``` [Agent 遇到高风险操作] │ ▼ [触发 Contact-Human Tool Call] │ ▼ [通过 Slack / 短信 / 邮件发送审批请求] │ ▼ [人类点击批准/拒绝] ───► [Agent 接收回调并继续运行循环] ```

> "我们能给软件的最有用的功能，往往也是最危险的功能。尤其是在由大模型驱动的这种非确定性系统里，这个矛盾更加尖锐。所以把人放进循环（Human-in-the-loop）里，这不是退步；想让强大的能力安全落地，这是唯一的办法。"

Dex 提到，他最初想做一个能自动清理数据库的 Agent，但绝对不能让 AI 无监督地执行 `DROP TABLE`。加入人类审批环节后，不仅保障了安全，更打通了高风险场景的落地路径。

---

[10:30](https://www.bilibili.com/video/BV1dEMS6QExa?t=630s) 规模化五原则（原则 8 - 12）

最后一组原则旨在保证 Agent 在真实复杂生产环境中的健壮性与可扩展性：

* **原则 8：掌控你的控制流（Own Your Control Flow）** 循环的重试策略、放弃条件、分叉逻辑等控制流决策权，必须掌握在开发者手中，不能盲目依赖框架的默认配置。 * **原则 9：把错误压缩进上下文窗口（Compact Errors into Context Window）** 工具报错时，如果把长串的原始 Traceback 堆进上下文，会瞬间塞爆窗口。开发人员必须对错误进行提炼和结构化压缩，仅把有价值的信息喂给 LLM，帮助其进行错误自我纠正。 * **原则 10：小而专注的 Agent（Small, Focused Agents）** 避免幻想构建无所不能的超级 Agent（Super Agent）。应将复杂任务拆解，遵循 UNIX 哲学与微服务架构思想，让每个小 Agent 专精于单一任务。 * **原则 11：随处触发，与用户相会（Trigger Anywhere, Meet Users Where They Are）** Agent 不应只局限于网页上的 Chat 窗口，而应能被 Cron 定时任务、Webhook、Slack 消息等任意事件触发，并主动前往用户所在的渠道（如邮件、社群等）进行交互。 * **原则 12：把你的 Agent 做成一个无状态的规约器（Make Your Agent a Stateless Reducer）** 这是最深刻的一条架构原则。Agent 本身应当是一个纯函数（Pure Function），其自身不持有内部状态。所有的状态均序列化存储于外部。每一次循环，Agent 都是拿着当前状态（State）和本轮输入（Action），计算出下一个状态。

``` State(t+1) = AgentReducer(State(t), Input(t)) ```

这种设计理念直接借鉴了前端架构 React 和 Redux 的核心思想。将 Agent 做成无状态规约器后，系统将具备极高的可测试性、可恢复性与横向扩展能力，是工程上最优雅、最易维护的形态。

---

[12:23](https://www.bilibili.com/video/BV1dEMS6QExa?t=743s) 工程师的清醒宣言

《12-Factor Agents》真正的价值，在于它不卖任何新框架，甚至劝诫开发者不要过度依赖框架。Dex Horthy 指出，将高质量 AI 软件交付给客户的最快方式，**绝不是押注某个框架然后推倒重来，而是从 Agent 开发中提取出那些小而模块化的概念，融入到已有的成熟产品架构中**。

AI 的爆发并未免除工程师做好传统软件工程的责任。正如十年前的《12-Factor App》梳理了云原生应用思路一样，《12-Factor Agents》在 Agent 狂热的浪潮中提供了一份冷静的工程师宣言：**哪怕底层大模型依然在以指数级变强，这些工程原则依然成立——因为它们解决的从来不是模型的智商问题，而是软件本身的复杂度问题。** 最顶尖的 AI 产品，底层支撑的依然是最朴素的工程纪律。

</ElicitationsGroup>

## Notable quotes > [02:34](https://www.bilibili.com/video/BV1dEMS6QExa?t=154s) 框架能帮你快速起跑，却把你困在八成的天花板下面。 — Dex Horthy

> [03:52](https://www.bilibili.com/video/BV1dEMS6QExa?t=232s) 好的 Agent，说到底主要就是软件。 — Dex Horthy

> [05:13](https://www.bilibili.com/video/BV1dEMS6QExa?t=313s) Agent 的本质就是一个循环（Loop）。 — Dex Horthy

> [09:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=540s) 将“询问人类”本身设计成一种标准的 Tool Call。 — Dex Horthy

> [09:00](https://www.bilibili.com/video/BV1dEMS6QExa?t=540s) 我们能给软件的最有用的功能，往往也是最危险的功能。尤其是在由大模型驱动的这种非确定性系统里，这个矛盾更加尖锐。所以把人放进循环（Human-in-the-loop）里，这不是退步；想让强大的能力安全落地，这是唯一的办法。 — Dex Horthy

> [10:30](https://www.bilibili.com/video/BV1dEMS6QExa?t=630s) 把你的 Agent 做成一个无状态的规约器 — Dex Horthy

> [12:23](https://www.bilibili.com/video/BV1dEMS6QExa?t=743s) 哪怕底层大模型依然在以指数级变强，这些工程原则依然成立——因为它们解决的从来不是模型的智商问题，而是软件本身的复杂度问题。 — Dex Horthy

## Mentioned 12-Factor Agents, 12-Factor App, Heroku, Adam Wiggins, Dex Horthy, Replicated, HumanLayer, Y Combinator (YC), Kubernetes, Slack, React, Redux, UNIX

[Source](https://www.bilibili.com/video/BV1dEMS6QExa)

中文简报

YC创业者推12因素智能体法则：弃用开源框架直接控核心生产级AI Agent难以落地源于过度依赖框架黑箱，开发者必须回归朴素软件工程并自主掌控提示词与状态管理。很多开发者在用开源框架构建 AI Agent 时，常在达到 70%~80% 完成度后陷入“死亡谷”，面临输出不稳定、上下文爆满及调试困难等生产瓶颈。演讲者指出 Agent 的本质其实是一个由“大模型决策-确定性代码执行-结果追加上下文”组成的简单循环，顶级开发者大多选择抛弃封装黑箱的复杂框架并自己实现。通过“掌控三件套”、“结构与生命周期”、“将人类当工具调用”以及“规模化五原则”（如将 Agent 做成无状态规约器），开发者能够将 AI 带来的不确定性纳入严密的传统工程控制之下，从而打造出真正具备抗造性的生产线系统。针对 AI Agent 在演示阶段表现亮眼、部署到生产环境即陷入失控的行业困境，开源项目《12-Factor Agents》梳理了一套指导生产级交付的工程原则。 (0:00) 《12-Factor Agents》致敬了 2011 年 Heroku 提出的《12-Factor App》，由 HumanLayer 创始人 Dex Horthy 发起。 (1:02) Agent 开发普遍存在“八成死亡谷”现象：框架能帮助开发者快速搭建 80% 的功能，但要突破剩余 20% 的生产级天花板，往往需要反向工程框架内部流程甚至推倒重来。 (2:34) 调查显示绝大多数真正做出顶级 Agent 产品的团队根本不使用开源 Agent 框架，而是自研底层代码。 (3:52) 好的 Agent 本质上主要就是软件，依靠的是朴素的软件工程而非玄学 Prompt 或 Agent 框架。 (3:52)

Reading summary

HumanLayer 创始人 Dex Horthy 基于对百余位 AI 创业者的调研，提出开源方法论《12-Factor Agents》，指出构建生产级 AI Agent 的核心不在于依赖现成的黑箱框架或追求全自动的“自主性”，而在于遵循严谨的软件工程纪律，由确定性代码全面掌控提示词、上下文、状态流转与人工安全介入。现成框架引发的“八成死亡谷” (2:34) 许多开发团队在构建 Agent 时倾向于借助开源框架快速搭建演示（Demo），但在面向真实客户时，普遍面临输出不稳定、工具调用频繁出错与上下文窗口被塞爆等失控问题。Dex Horthy 指出，绝大多数团队都会落入“八成死亡谷”：框架能帮助产品迅速达到 70% 至 80% 的完成度，但若想突破剩余 20% 的生产级天花板，开发者不得不对框架内部封装的提示词（Prompt）与状态管理进行反向工程，最终往往因无法维护而被迫推倒重来。调研发现，Y Combinator 等顶尖团队的 Agent 产品绝大多数不采用开源框架，而是从底层自研。Dex 认为，市面上真正落地的 Agent 产品在本质上“并不那么 Agentic”，其主体仍是高度确定性的软件代码，大模型仅在少数关键节点参与决策。构建可靠系统的关键是朴素的软件工程，而非将控制权完全移交给让模型自由死循环的黑箱。极简执行循环与掌控权回归 (5:13) Dex 将 Agent 的本质精简为一个由三步组成的确定性循环：大模型依据上下文做出决策并输出结构化工具调用（Tool Call）、确定性代码执行该工具、执行结果追加（Append）回上下文窗口，循环反复直至任务终结。为了防止该循环在实际部署中崩溃，开发者必须落实“掌控三件套”（原则 1 至 3）。系统首先需要一套稳定的机制，将用户输入的自然语言精确转换为后端可识别的结构化工具调用（原则 1）。其次，开发者必须能够完全看见并自由精调每一个 Prompt（原则 2），拒绝使用将提示词封装在内部的黑箱框架。此外，作为模型短期记忆的上下文窗口（原则 3）必须由开发者显式管理，主动把控信息的载入、清理与压缩时机，避免放任框架黑盒逻辑将窗口填满。统一状态生命周期与人类工具化 (7:49) 在系统架构与生命周期层面，原则 4 指明工具调用的本质就是符合特定 Schema 的结构化数据输出，开发者应使用统一的工程规范处理工具、结果与报错。原则 5 强调应将 Agent 的执行状态（如执行步骤和调用记录）与业务状态整合在同一存储层统一管理，避免多头存储造成状态割裂。针对长时运行任务（Long-running Tasks），系统需提供简洁的接口支持随时挂起、持久化并在条件成熟时恢复运行（原则 6）。针对删库、发邮件或资金转账等高风险操作，原则 7 提出了将“询问人类”本身设计为标准工具调用（Contact Humans via Tool Calls）的方案。Agent 遇到危险指令时，触发审批工具向 Slack、邮件等渠道发送请求，在人类操作员批准或拒绝后通过回调继续推进循环。这种将人类置于循环中（Human-in-the-loop）的机制，在不牺牲自动化价值的前提下打通了高危场景落地的安全路径。规模化工程与无状态规约器架构 (10:30) 为保证 Agent 在真实复杂环境中的容错与扩展能力，原则 8 至 12 确立了系统级的工程规范：开发者必须自控循环中的重试、放弃与分叉等控制流逻辑（原则 8）；工具报错时，系统应提炼并压缩错误信息后再追加至上下文，避免原始 Traceback 堆积（原则 9）；放弃全能型 Super Agent 幻想，遵循 UNIX 哲学拆解出专注于单一职责的小 Agent（原则 10），并支持通过 Webhook 或定时任务随处触发交互（原则 11）。该体系中最具深度的架构原则是将 Agent 构建为一个无状态的规约器（Stateless Reducer，原则 12）。借鉴 React 和 Redux 的纯函数思想，Agent 自身不保留内部状态，所有状态均在外部序列化存储。每一轮循环中，Agent 仅接收当前状态与输入数据计算出下一状态。这种设计消除了隐式状态依赖，显著提升了系统的可测试性、故障恢复能力与横向扩展弹性。《12-Factor Agents》并未推销任何新框架，而是建议开发者将小而模块化的 Agent 概念逐步融入既有的成熟系统。Dex Horthy 总结道，即便底层大模型持续演进，这些工程原则依然坚固，因为它们解决的是软件工程本身的固有复杂度，而非单纯依赖模型智商的提升。

Source quotes

[2:34] Dex Horthy: 框架能帮你快速起跑，却把你困在八成的天花板下面。 [3:52] Dex Horthy: 好的 Agent，说到底主要就是软件。 [5:13] Dex Horthy: Agent 的本质就是一个循环（Loop）。 [9:00] Dex Horthy: 将“询问人类”本身设计成一种标准的 Tool Call。 [9:00] Dex Horthy: 我们能给软件的最有用的功能，往往也是最危险的功能。尤其是在由大模型驱动的这种非确定性系统里，这个矛盾更加尖锐。所以把人放进循环（Human-in-the-loop）里，这不是退步；想让强大的能力安全落地，这是唯一的办法。 [10:30] Dex Horthy: 把你的 Agent 做成一个无状态的规约器 [12:23] Dex Horthy: 哪怕底层大模型依然在以指数级变强，这些工程原则依然成立——因为它们解决的从来不是模型的智商问题，而是软件本身的复杂度问题。

Original transcript

[0:00] 你有没有过这样的经历?兴致勃勃地用某个agent框架搭了一个看起来很酷的AI助手演示的时候经验全场,可一旦要把它真正交给客户用,事情就开始失控。输出不稳定,工具调用出错,上下文莫名其妙就被塞爆,你花在调整提示词上的时间,比写业务代码还多。到最后你发现自己不是在做一个产品是在给一个黑箱擦屁股这不只是你一个人的问题一整个行业都被这个卡着而有一个开源项目,专门来回答一个问题,到底要用什么原则,才能构建出真正构格交给生产客户的AI软件?他在GitHub上拿下了25000颗星,他叫12Factor Agents,12因素智能体。这期视频,我们就来好好聊聊它。12 Factor Agents 光听名字你可能觉得有点眼熟没错,他在致敬一份十年前的经典。2011年,Hairco的工程师Adam Wiggins写了一份文档,叫12Factor App,12因素应用。那份文档用12条原则定义了什么叫一个现代的、可扩展的、能在云上跑起来的应用。他没有发明什么新技术,但他给一整代开发者提供了一套共同语言。直到今天你在任何一家公司聊软件架构都绕不开它12 Factor Agents 做的是同一件事,只不过对象换成了 AI Agent。他同样用12条原则试图回答什么样的LLM应用,才算真正够格交给生产客户。这份《方法论》的作者叫Dex Horty他在一家叫Replicated的公司干了7年,专门帮别的团队把产品改造成能在Kubernetes上跑的云原生版本。他做过容器编排,带过产品团队,还创立了公司的市场部门。2023年,他自己出来创业,成立了Human Layer,拿到了Y Combinator 的投资。HumanLayer做的事情很有意思,它让软件能够在关键操作时联系人类,去获取批准和反馈。听起来不起眼,但这正是后面第七条原则的核心。我们先记住这个名字在正式讲12条之前,Dex先戳破了一个让很多人扎心的事实。他聊过至少100个想把产品做成Agent 化的创业者,他们的经历几乎一模一样,可以总结成七步。第一步,决定要做一个Agent。第二步做产品设计想清楚要解决什么问题第三步,为了赶进度,随便抓一个现成的框架就开始写。第四步很快做到七成到八成的完成度第五步,发现这八成对面向客户的功能来说,根本不够用。第六步意识到要突破剩下的两成得反向工程那个框架的提示词流程状态管理第七步推导重来这就是他说的Agent开发的死亡股。框架能帮你快速起跑,却把你困在八成的天花板下面。那些他认识的真正做出了厉害产品的创始人,无论是在YC里面还是外面,大多数根本不用框架。他们都是自己录一套这本身就说明一个问题,现成的Agent框架,在生产环境里,可能并没有它宣称的那么好用。接下来是整个方法论最反直觉也最重要的一句话Dex说,他很惊讶地发现,市面上大多数把自己标榜为AI Agent的产品,其实并不怎么Agentic。它们当中很多,主体就是确定性的代码,只是在几个恰到好处的位置,点缀了一些大模型的步骤,让体验变得很神奇。换句话说,你以为那些酷炫的AI产品背后是一个无所不能的自主智能体?实际上,它可能就是一堆判断逻辑,中间夹着几次大模型调用。而真正好的Agent 也不遵循那个被吹捧的范式什么范式呢?就是给你一个提示词,给你一袋工具,让它自己循环,直到达成目标。DEX的结论很尖锐,好的Agent,说到底,主要就是软件。这话的分量在于,他给整个行业的agent狂热浇了一盆冷水。他告诉我们,构建可靠的AI应用,靠的不是更玄学的提示词,不是 [5:00] 动画少的框架,而是最朴素的软件工程。这正是12 Factor Agents 这个名字的用意他没打算给你一个新玩具,他的作用是把你拽回工程的基本功。那agent 到底是什么?DEX给了一个非常清醒的定义他说,别把agent想得多神秘,它的本质就是一个循环。这个循环只有三步第一步,大模型根据当前的上下文,决定下一步该做什么,输出一个结构化的工具调用。第二步,一段确定性的代码,负责真正执行这个工具调用。第三步,把执行结果追加回上下文窗口里。然后,重复这个过程,直到大模型判断任务完成。你看,Agent的全部秘密就在这。它谈不上是个有自我意识的数字生命,它就是一个循环。但问题来了。Dex也很坦诚地说,这个看起来很优雅的循环,实际跑起来,并不如我们期望的那么好。よう他会犯错,会跑偏,会把上下纹塞爆,会在不该停的时候停。所以才需要接下来的12条原则这12条要解决的就是怎么把这个循环工程画让它从一个不靠谱的玩具变成一个能在生产环境抗室的系统我们正式进入十二条原则为了方便理解,我按主题把他们分成了几组。第一组,我称之为掌控三件套,对应前三条原则。他们的共同主题是一个字:空。第一条:自然语言转工具调用这是Agent 的入口用户说的是人话,但你的系统需要的是结构化的指令。这一条要求你有一套清晰的机制,把非结构化的自然语言稳稳地翻译成结构化的工具调用第二条,掌控你的提示词。这一条是冲着框架去的很多框架喜欢把提示词封装在黑箱里,你觉得方便,但等你需要精调的时候,根本摸不到。DEX的态度很明确,提示词是你的,你必须能完全看见它,修改它。第三条,掌控你的上下纹窗口。这是最被低估的一条。上下文窗口就是大模型的短期记忆,它就是你的内存。哪些信息该塞进去,哪些该清理出去,什么时候该压缩,必须由你主动管理,而不是交给框架虾田。这三条合起来就一句话,在Agent 的世界里,放弃控制权。就等于放弃产品质量第二组原则讲的是Agent 的结构和生命周期第四条,工具就是结构化输出。这句话的意思是别把工具调用想的多特殊它本质上就是让大模型输出一段符合特定格式的结构化数据。理解了这一点你就能用同一套思路去处理工具处理结果处理错误第五条,统一执行状态和业务状态。Agent 在跑的过程中会产生状态,比如执行到哪一步了,调用了哪些工具。这些执行状态应该和你的业务数据放在同一个地方管理而不是单独搞一套Agent专属的存储。否则你的系统迟早会顾此失比第六条,用简单的接口实现启动、暂停、恢复。Agent 往往是长时间运行的任务,他不可能一直占着资源不放手。你必须能让他随时停下来,存好状态,等条件满足了,再接着跑。这一条是Agent从玩具走向生产线的关键一步接下来这条是整个12条里最特别的一条,也是HumanLayer这家公司的核心。它就是第七条用工具调用来联系人类什么意思呢?Agent 在执行任务时难免会遇到高风险的操作,比如删数据、发邮件、执行支付。让他自己擅自干,太危险可如果每一步都让人盯着,又失去了自动化的意义。Dex给出的解法非常巧妙,把询问人类也设计成一种工具调用。当Agent遇到拿不准的关键操作,他就调用一个联系人类的工具。通过 Slack 短信邮件去问人一句这个操作批准吗?人回复了,Agent 再接着跑。这个想法正是DEX创立Human Lair的起源。他当初想做一个能自动清理数据库的agent,要让他能删表。他 [10:00] 处不能让一个AI在没有监督的情况下跑山表语句于是他加了一道人类批准的环节那一刻他琢磨出一件事我们能给软件的最有用的功能往往也是最危险的尤其在由大模型驱动的这种非确定性系统里这个矛盾更加尖锐所以把人放进循环里这不是退步想让强大的能力安全落地这是唯一的办法最后这一组原则覆盖第八到第十二条讲的是怎么让agent在真实世界里规模化稳健地跑起来第八条掌控你的控制流还是那个字控循环的逻辑什么时候重视什么时候放弃这些决策权必须在你手里不能交给框架的默认行为第九条把错误压缩进上下文窗口agent会犯错工具会报错如果把一长串原始报错信息全部塞回上下文很快就会爆掉这一条要求你学会提炼错误只把有用的信息喂给大模型第十条小而专注的Agent别幻想做一个无所不能的超级Agent把任务拆开让每个Agent只专注做好一件事这根微服务跟UNIX哲学是一个路子第十一条随处触发与用户相会Agent不应该只活在你的网页对话框里它应该能从任何地方被触发一个定时任务一个网络勾子一条slag消息然后主动去用户所在的渠道里找他们第十二条把你的Agent做成一个无状态的规约器这是最深刻的一条意思是Agent本身应该是一个纯函数它不持有状态所有的状态都序列化存在外部每次循环都是拿着当前的状态和这一步的输入算出下一个状态听起来耳熟吧没错这就是React和Redux的核心思想把Agent做成一个无状态的规约器它就变得可测试可恢复可扩展这是工程上最好打理的形态12条原则讲完了我们退一步看12Factor Agents真正的价值到底是什么Dex在文档里说了一句很关键的话他见过最快的把高质量AI软件交到客户手里的方式不是压住一个框架推倒重来而是从Agent开发里提取出那些小的模块化的概念把它们融进现有的产品里这句话点破了整份方法论的立场它不卖框架甚至反过来劝你别太依赖框架它是在告诉你AI没有免除你做好软件工程的责任十年前的12Factor App帮一整代人理清了云元生应用的思路今天的12Factor Agents想做同样的事而且它有一个底气哪怕大模型还在指数级变强这些工程原则依然成立因为他们对付的不是模型的智商而是软件的复杂度在一个到处都在吹Agent神话的时代这份25000颗星的开源文档更像是一份给工程师的清醒宣言它提醒我们最性感的AI产品底层也是最朴素的工程纪律12 Factor Agents不算一个框架它更像一种思维方式

YC创业者推12因素智能体法则 弃用开源框架直接控核心