智能体软件工厂的需求层次
你是不是已经受够了 babysitting Codex、Claude Code 或 OpenClaw？
你有能构建功能的智能体，但你仍然要负责记住它们停在哪里、解释每个功能如何融入项目、决定下一步做什么。你在每次对话中取得进展，然后开发就停在那里等你回来。
其实不必如此。软件工厂可以让你把这个流程的更多部分委托出去！
你和系统就一个结果达成一致，给它所需的上下文和权限，然后让它在你做别的事时工作。当你回来时，应该看到：
- 一个可以检查的结果，附带检查了什么的证据；或者
- 一个工作无法继续的具体原因。
这样你的下一次对话就可以聚焦于结果和剩余的决定。
正如我们将要展示的，你的第一个软件工厂根本不需要那么复杂：它可以始于一个智能体和一个自动化任务。
1、什么让它成为"工厂"
定义性的组合是自主且异步的执行。
- 自主（Autonomous）：智能体自主选择并执行达成目标的步骤。它可以检查发生了什么、调整方法，并在其权限范围内继续。
- 异步（Asynchronous）：这项工作可以在你持续关注之外进行。你可以离开，再回来看结果。
定时任务可以在没有你的情况下运行。编码智能体可以在交互会话中选择和修正方法。工厂把这两种能力结合起来，配上足够的上下文、工具和反馈来完成委托的工作。
软件工厂的概念已经被假设了几十年。现在我们有了智能体，才真正能运转它们。这些原则适用于传统上由人类团队完成的软件工作——从为团队和个人定制的工具，到大型复杂软件系统。
为了说明这些原则，我们全文用一个发票追踪器做例子——这是我们自己业务需要的应用。同样的方法也适用于研究工具、出版系统和团队软件。假设你经营一家小企业，想要一个贴合你工作方式的发票追踪器：
构建一个应用：根据我的模板生成发票，追踪哪些未付、已付或逾期。暂时保持本地运行。重启时保留记录，并展示检查结果证明总额和支付状态是正确的。
你可以和智能体就这份简报达成一致，把它留在那里工作，然后回来看应用和检查证据。如果某项检查失败，它可以在约定范围内调查和调整。如果遇到它无法做出的产品决策，它应该把问题带回来给你。
你可能会想象一种干净的分工：工厂构建发票追踪器，然后成品应用干自己的活。这是一种运行方式。但智能体也可以帮助运维它们构建的软件，这种组合很有用。
追踪器可以存储发票并计算未结余额。智能体可以利用这些记录，结合客户往来沟通来准备跟进：一个客户承诺周五付款；另一个正在对一笔费用提出异议。你不需要在智能体帮忙之前把每种情况都变成新的软件功能。你给它相关的上下文、权限和检查工作的方式。
这改变了你需要构建什么！有些行为属于代码，比如一致地计算余额。其他工作可以委托给一个根据情况响应的智能体。如果出现了重复性需求，你可以让工厂把它做进软件里。工厂构建智能体可以使用的工具，而使用这些工具的经验又帮助你决定下一步构建什么。
你仍然决定什么值得构建、为谁服务、哪些权衡更重要。智能体也可以帮助你做这些决定。实际的变化是：实现可以在你的对话之间推进，包括运行检查和响应失败。
这也让工厂与拥有产品、商业或创作专长的人（而不仅是工程师）相关。你可能很清楚如何给客户开票、记录付款和催收逾期账款，但对写软件没多大兴趣。这些知识让你能指挥工厂构建贴合你业务的软件，包括通用工具处理不好的例外和连接。
2、软件工厂的需求层次
每一层都是：明确你想要什么以及如何检查成功，然后验证结果。
Monica Rogati 最初的 AI 需求层次描述了成功 AI 工作之下的基础。我们发现这种依赖关系框架对工厂也有帮助，分为四个不同的层次：
- Harness（运行环境）。模型周围的环境：工具、项目文件的工作区、执行和反馈。它让智能体能够读取文件、修改软件并运行它。如果检查失败，Harness 必须给智能体足够的信息来调查发生了什么。
- Personalisation（个性化）。你的工作的上下文和能力：项目方向、规则、参考材料、技能和与其他系统的连接。智能体需要知道你试图完成什么、哪些既有决策应该保留。权限限制对工具和系统的访问；沙箱限制动作可以运行的环境。
- Automation（自动化）。一种无需你每次下达新指令就能启动和继续工作的方式。定时或事件可以触发任务或拾取就绪的工作。它还需要关于什么算就绪、结果放在哪里的指引。
- Continual learning（持续学习）。一个从已完成和失败的运行中学习、改进工厂并把改动带入后续工作的流程。这可能改变一条指令、一个检查程序或智能体使用的工具。
Automation 需要一个能完成工作的 Harness，加上关于做什么的指引。Continual learning 需要可供检查的运行和一种把改进投入使用的途径。这些能力可以共同发展：一个熟悉的 Harness、一份简短的简报和一个基本的自动化就足够起步了。随着工作暴露出缺失，你可以进一步个性化。
有两项实践贯穿每一层：规格（specification）和验证（verification）：
- 规格让预期结果、约束和成功标准变得明确。在我们的发票简报中，这包括重启后保留记录、正确计算支付状态。
- 验证对照这些要求检查软件和智能体完成的工作。
智能体可以帮助你完善规格并执行检查。你的角色是决定这些需求是否覆盖了你的需要，以及证据是否支持接受结果。随着工厂承担更多工作，这些实践给了你指挥它和评估返回结果的方法。
现在让我们看看每一层里有什么。
2.1 智能体 Harness
首先，你需要一个智能体 Harness。如果你在用 Codex、Claude Code、Hermes 或 OpenClaw，你已经有了一个。它给模型提供读取和编辑文件、运行你的软件并查看发生了什么的工具。
对于我们的发票追踪器，智能体可以构建应用、创建发票、记录付款，并重启它检查发票和付款记录是否存活。如果一张已付发票仍显示逾期，它可以调查、修复问题并重试。你不应该不得不叙述每一步。但如果它需要关于你的业务如何处理部分付款的决定，那是你的问题。如果它缺乏访问权限或授权，智能体应该停下来并明确指出阻塞点。
你还需要一个让 Harness 运行的地方。云端机器让智能体在你的笔记本合盖或断网时继续工作。你也可以在自己的电脑上运行，但机器需要保持唤醒和联网，工作才能继续。
2.2 个性化
接下来，给智能体按照你的方式工作所需的上下文。对于我们的发票追踪器，这意味着你的模板、付款条件和记录付款的惯例。你不想每次开始新任务时都重新解释这一切。
把它保存在未来工作者能找到的地方：
- 规则：保留现有发票记录；更改支付状态计算前先询问。
- 参考资料：你的模板、付款条件和发票示例。
- 技能：测试发票创建、付款更新和持久化的可重复流程。
诸如 AGENTS.md 之类的指令文件可以指向这些材料。OpenAI 的 harness 工程实践描述了使用简短指南指向维护良好的项目文档。给新来的或定时工作者一个小任务，检查它是否真的遵循了指引。
要明确指令何时适用。Eleanor 曾让一个智能体写测试，它给 README 写了测试。热情不是问题 😂
你还需要设置权限和沙箱来控制智能体可以访问和执行什么。仅靠书面指令无法强制执行这些边界！
2.3 自动化
一个智能体在后台工作；你评估返回的结果。
现在让工厂有一种不等你就能启动的方式。定时或事件可以带着简报、项目指引和工具启动一个智能体。你回来时看到一个结果、检查了什么的证据，或一个需要你关注的具体阻塞点。
一个智能体在后台工作
对于我们的发票追踪器，早上的自动化可以检查已保存的任务列表并拾取下一个约定的任务，比如添加部分付款。你已经决定了你想要什么以及如何检查成功。智能体在你做别的事时继续推进。
有几个实际细节要处理好：不要重复启动同一个任务；不要动空队列；设置时间和花费上限。保存进度，这样后续会话可以继续，你不必重建整个对话。
一个工作者可能就够了。但也许你有可以并行的独立任务，或者你想让另一个智能体评审一次改动。这就是协调登场的地方。
协调就绪的工作，然后检查合并后的结果。
协同工作
有多个智能体时，所有人都需要一个能看到什么就绪、什么在进行、什么在等别处的地方。共享任务列表或问题追踪器可以保存这些信息。你确认哪些任务就绪；一个协调智能体或自动化分配它们、提供相关上下文并记录发生了什么。
假设一个任务添加部分付款，另一个处理逾期跟进邮件，第三个做 PDF 导出。跟进需要正确的未结余额，所以它们要等付款行为被检查过。如果改动不重叠，PDF 导出可以独立推进。
你也可以拆分角色。一个智能体构建功能，另一个准备测试用的付款场景，第三个评审完成的改动。
指定合并改动和验证整个应用的责任。不同的问题需要不同的检查。确定性测试可以确认余额计算是否正确、付款是否在重启后存活。智能体验证可以帮助发现被遗漏的需求或改动之间的不一致。人类判断可以评估工作流是否贴合你实际的工作方式。你通常会想要组合——对同一个结果做多种检查。Anthropic 的评估指南描述了这些互补的方法：基于代码的检查、基于模型的检查和人类评估。
根据你要确立的内容，组合确定性检查、智能体验证和人类判断。
一旦你确认组合后的功能能协同工作，你可能会让工厂构建一个手机友好的界面，这样你可以在移动中检查发票和记录付款。
工厂也可以帮助运行开票工作流并改进其软件。定时智能体可以审查逾期发票、查阅客户往来沟通，并准备跟进供你批准。如果这项工作反复需要追踪器没有记录的信息，你可以给工厂一个添加它的任务。构建和运维相互喂养：智能体使用软件，使用中发生的事情又指导下一次改进。这就把我们带到了持续学习。
2.4 持续学习
用运行证据来测试和采纳对后续工作的改进。
你的工厂也可以在工作方式上变得更好。假设付款在发票追踪器重启后消失了，尽管智能体报告检查都通过了。你当然希望它修复 bug。但为什么它的检查漏掉了这个问题？
保留任务分配、检查和困难的记录，这样评审智能体可以识别反复出现的问题并提出改进。是工作者缺少重启应用的方式，还是它干脆跳过了那项检查？
如果它跳过了检查，智能体可以提议一个技能：每当改动影响存储的记录时，保存付款、重启应用并验证剩余余额。先用原始失败测试它，再在更多任务上测试。它能发现存储的客户详情问题吗？当任务只改了一个标题时，它能避免不必要的检查吗？
这些结果帮助你决定采纳、修改还是拒绝这个方法。在你已授权的范围内应用改动，并保持可逆。Warp 的自我改进工厂说明了这种方法：失败的检查可以导致对提示词、技能或配置的改动建议，连同运行证据一起提交人工评审。
随着项目和模型变化，重新评估方法。Anthropic 关于长时间运行的应用开发的工作描述了随着模型能力提升而移除流程并检查效果的做法。
一个保存下来的教训需要触达后来的工作者并改进他们的结果。这种学习通过改变模型周围的指令、工具和方法发生，而不需要重新训练模型本身。
3、你会构建什么？
你的工厂可以构建一个收集来源并让你组装简报的研究工具、一个共享计划和文档的家庭内网，或一个私密社区空间。从对你有用的东西开始，然后随着发现缺失，给工厂更多工作。智能体也可以帮助运维你构建的东西——从准备研究简报到整理收到的材料。
Hugo 用这种组合运营 Vanishing Gradients——他的媒体和教育业务。嘉宾准备电话后，一个自动化获取转录稿并准备采访主题、问题、标题和缩略图选项供审阅。直播后，智能体可以提议片段、剪辑视频、加字幕并准备上传草稿。保存的编辑指引和技能塑造工作；Hugo 决定发布什么。
他也维护这个系统：当智能体漏掉指令时改进检查，根据结果更新技能。更自主的持续学习仍是他正在探索的方向。他在《我如何用智能体软件工厂建立了一个媒体帝国》中描述了这套配置。
有什么简单的任务你为社区、受众或业务反复执行，可以开始自动化的？
4、决定你的工厂下一步需要什么
看看是什么不断把你带回这项工作。如果智能体无法运行应用或检查失败，改进 Harness。如果你不断重复项目上下文和决定，个性化它。如果开发要等你启动每个任务或管理每次交接，添加自动化。如果同样的失败在运行中反复出现，建立一个学习循环来改变后续工作的进行方式。
从你关心的工作开始，检查返回的结果。一个智能体可以使用全部四个层次。在它们帮助你委托更有用的工作的地方添加能力，同时让规格和验证始终是流程的一部分。
原文链接: The Agentic Software Factory Hierarchy of Needs
汇智网翻译整理，转载请标明出处