Charlie Holtz 反对把 agent 系统只叫工厂

Charlie Holtz 的标题叫 “Orchestras, not Factories”。这句话不是反对 software factory，而是在提醒大家：如果只用工厂隐喻，容易把 agent 系统想得太机械。

原视频：https://www.youtube.com/watch?v=htM02KMNZnk

Conductor 想做的是编排

Charlie 讲 Conductor 的产品思路。转录里可以看到，他展示内部 agent、workspace、Git worktree、Conductor API、从手机或 Telegram 触发工作，以及 agent 在后台继续执行。

这些设计更像编排，而不是流水线。流水线强调固定步骤和吞吐。编排强调不同角色、不同上下文、不同节奏之间的协调。agent 不是每次都做同一种零件，它经常要处理开放问题、协作状态和人的临时指令。

他还提到，早期 Conductor 的每个任务都建立在 Git worktree 上。worktree 很适合隔离 agent 的改动，但随着使用场景变复杂，团队还需要更自由的 workspace、更好的 handoff、更自然的人机协作界面。

人不应该只当监工

Charlie 的一个判断很有意思：他不想坐在那里看 agent 一行行输出。他希望自己还在 flow 里，像和一组人以及 agent 一起做东西。

这句话击中了很多 AI coding 工具的问题。它们让人从写代码变成看 token 滚动，从创造者变成监工。表面上自动化了，实际把人的注意力锁在更无聊的位置。

Conductor 的方向，是让 agent 在后台建 workspace、做任务、提交可检查结果。人可以从手机、Telegram 或界面里发起和检查，不必一直守着终端。

这也是为什么他用 orchestra，而不是 factory。orchestra 里每个角色都有节奏，指挥不是替每个人拉琴，而是让不同声部进入合适位置。

工厂和乐队都需要

我觉得这场最好的用法，是修正大家对 software factory 的想象。底层当然需要工厂：任务要可重复，测试要可自动化，权限要可控制，失败要可复盘。

但上层更像乐队。多 agent 和多人协作时，状态不是一条直线。某个 agent 在跑实现，另一个 agent 在查资料，人类在改 spec，CI 在失败，产品临时换了目标。系统要让这些声部可见、可暂停、可恢复。

所以，”factory” 适合描述可验证的重复工作，”orchestra” 适合描述复杂协作。真正成熟的 agent 系统，两者都要有。只有工厂会太僵，只有乐队会太散。

为什么“乐队”这个比喻更贴近真实协作

Charlie 反对只用 factory，不是因为工厂比喻完全错，而是因为软件开发有太多开放协作。工厂强调标准化和吞吐，但 agent 系统经常面对的是不确定目标、变化中的上下文和人的即时判断。

Conductor 展示的手机入口、Telegram 触发、后台 workspace 和 Git worktree，都在说明一个产品方向：agent 不必占满人的屏幕。它可以像团队成员一样在后台推进，等需要判断时再把结果交给人。

这比“看着模型写代码”更健康。人类不应该被困在 token 流里。真正有价值的是在正确时间介入：改方向、给权限、确认 tradeoff、检查结果。

协作界面会成为新战场

多 agent 时代，界面不是皮肤，而是能力。一个系统如果只把十个 agent 的日志堆给你，你会更累，不会更高效。好的协作界面要压缩状态，让你一眼知道哪个任务在跑、哪个卡住、哪个需要 review、哪个已经可合并。

Charlie 的 orchestra 说法提醒我们，agent 产品的竞争不只是模型和工具调用，也包括节奏管理。什么时候并行，什么时候等待，什么时候汇报，什么时候把任务拆给另一个 agent，这些都是编排。

工厂负责确定性，乐队负责变化

我会把这场放在 Tereza 之后读。Tereza 给出工厂底座：身份、权限、trace、CI、模型路由。Charlie 补上协作层：人和 agent 如何在变化中保持 flow。

如果只要确定性，流水线就够了。但软件开发不是纯流水线。产品会改，需求会变，旧代码会反抗，人会临时插入新判断。成熟系统必须同时容纳确定性和变化。工厂让它可靠，乐队让它灵活。

来源与说明

本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息，以及本地 AI engineering 知识库整理。文章不是逐字稿，而是按单场分享的主线、上下文和工程启发重写。