专栏 · Agent 工程手艺 › 第 191 期 · AGENT 工程 · 收录于 2026 年 8 月 23 日
幕后的 Agent:构建 Oz 云端 Agent 平台——Safia Abdalla(Warp)
SA
Safia Abdalla · AI Engineer
2,886观看
46赞
1.6%点赞率
2评论
62.7万频道订阅
数据截至 8 月 27 日
TL;DR · 三句话
- 一Warp 云端 agent 平台 Oz 的一条总原则是「平台在复杂性触达用户之前先把它扛下来」，落成四个原语设计：sandbox 托管 + 自托管并存、兼容任意 harness 但用平台护栏防体验碎片化、调研 / 实现 / 验证拆给不同 harness 和模型的 sub-agent、以及为栈里每个组件都开 API 让别人在上面搭。→ 详细
- 二这套原语在 Warp 开源（三个月内 GitHub 星 2 万→6 万+、几千个 PR）时被真刀真枪验证：agent 自动分诊 issue、反向追问细节，所有 PR 先过 agent 多轮 review、agent 批准前不 ping 任何人类 reviewer，且 review agent 随进来的代码样例持续自我改进。→ 详细
- 三她反对「软件工厂」这个词（「人在哪儿呢？」），用陶艺师的工坊替代：重点不是杯子而是支撑杯子诞生的可重复系统——能响应真实事件、可观测、随时间自我改进、控制成本——目标是把苦活累活从软件流程里去掉，让非开发者也能把意图变成实现。→ 详细
01
讲者是谁：8 年开发者工具老兵，从 Jupyter 到 Microsoft 再到 Warp
- Safia Abdalla 自述做了 8 年开发者工具：起点是 Python / 数据科学开源圈（Jupyter Notebook 核心团队、nteract 项目维护者），之后在 Microsoft 给 Web 开发者做 API 和 SDK，现在在 Warp 负责「把 AI agent 搬到云端」。本场标题《幕后的 Agent》讲的就是 Warp 云端 agent 平台怎么搭，但她坚持先讲「为什么」再讲「怎么做」。→ 详细
02
好的开发工具「在开发者所在之处接住他们，再跟着他们成长」
- 她 8 年攒下的核心信条：每天用的工具既要适配你现有的工作流，又要在工作复杂度变化时跟着变。理由是开发工具有复利效应——「如果你做的软件能帮一个开发者把活干得更漂亮，你放大『世界上好软件总量』的能力就变强了」。→ 详细
- 工作流之所以重要，是因为人有偏好：偏爱的 shell、语言、harness（agent 的「驾驶舱」——管提示词、工具调用、循环逻辑的那层外壳程序，如 Claude Code、Codex）、review 流程。顺着偏好走的工具用起来更舒服，还会「慢慢变成你思考和构建方式的一部分」。→ 详细
03
从本地终端到云端 agent：为什么笔记本「到头了」
- Warp 的三段演进，也是很多开发者工具的共同故事：AI 之前是 Warp 终端，接住命令行工作流；AI 来了之后，人们在终端 / IDE / 编辑器里本地跑 agent 式编程；再往后发现「在笔记本电脑上能做的事差不多到头了」——想让 agent 干更长时间、适配不同约束条件的活，就必须上云。→ 详细
- 代价是：任何东西一上云，就得背上「混乱得多的基础设施问题栈」。她特别说明这里的「我们」指做开发者工具的人——复杂性是被平台方背走的，不是用户。→ 详细
04
核心设计原则：平台在复杂性触达用户之前先把它扛下来
- 原话：「platforms should take on complexity before it reaches the user」——真正好的体验不该把内部处理的、会「漏出来」的复杂性暴露给你。Oz 平台的每一个原语（primitive，平台提供的最基础积木，如「一个沙箱」「一个任务」）都被有意设计成体现这条哲学，让用户只专注对自己重要的工作。→ 详细
- 这条原则第一个落点就是：agent 不在开发者机器上跑，那它在哪儿跑？→ 详细
05
Sandbox 的第一直觉错了：托管之外必须支持自托管
- agent 和人一样需要一个干活的地方，即 sandbox（云上的隔离环境）。Warp 最初的直觉是只提供托管式 sandbox，让开发者「不用操心算力在哪儿，它就在那儿等你用」，上手门槛最低。→ 详细
- 现实打脸：「真正干正经活的团队，多半在管理自己的基础设施」，有自己的 dev box 要对接，纯托管「通常是不够的」。agent 工作负载必须能跑在用户自带的基础设施上，才能适配其安全要求、部署实践和团队偏好。于是平台同时支持 managed（托管）和 self-hosted（自托管）——「这又是一层从用户那里抽象掉的复杂性」。→ 详细
06
多 harness 支持：灵活性不能「硬塞」，要靠平台护栏防碎片化
- harness 是比 sandbox 更「私人」的选择。她现场问谁本地偏好 Claude Code、谁用 Codex、谁用别的——「这屋里的口味太多样了」，所以平台要能接任何 harness，既照顾偏好，也让人「用对的工具干对的活」。→ 详细
- 关键警告：「灵活性不是往平台里硬塞进去就完事的，硬塞的真正风险是体验碎片化」——用 Claude、用 Codex、用自定义 harness 三种体验各不相同。解法是平台在 harness 外面提供结构和护栏，让任何 harness 都能接入全部平台原生能力：存储并恢复会话状态、以同一种方式组织 agent 产出的工件（PR、issue、新生成的文件）。→ 详细
07
一个 agent 不够用：调研 / 实现 / 验证分给不同 agent、不同模型
- 「我也希望只发一个 prompt 就能解决软件里所有问题，但真正的工程工作很少能塞进一个 prompt 里。」典型工作流是一个 agent 调研问题并规划方案、另一个实现、第三个验证。→ 详细
- 她的加分建议：让这几个 agent 各用不同的 harness 和不同的模型，才能形成「真正对抗式（adversarial）、稳健的做法」——同一个模型既写又审，容易互相放水。→ 详细
08
编排的两条路：一句 `/orchestrate` 的 prompt 式，与「每个组件都有 API」的平台式
- Oz 内置了跨技术栈的 agent 编排。最常见的是 prompt 式：输入
/orchestrate 或直接在 prompt 里说「把这个任务拆给多个 sub-agent」，编排 agent 就在幕后干所有脏活——和各 sub-agent 交互、在它们之间传消息、跟踪进度——「全凭一条 prompt」。→ 详细
- 她认为更有意思的是 API 式：Oz 整个产品表面都通过 API 暴露，可以发一个请求「跑一个 sub-agent、按我的配置挂到某个父 agent 下」。原话：「这个 API 特别神奇，因为它是一个平台的关键组成部分——它把原语以用户可以在上面继续构建的方式暴露出来」；好 API / SDK 的意义是「别人不再被你的 UI、或你对『某种体验该长什么样』的看法所束缚」，可组合性由此而来。→ 详细
- 具体做法是有意识地为栈里每一个关键组件都开 API：拉起 agent / sub-agent 的、管理环境与算力的、处理产出工件的。任何人都能在这些 agent 体验之上叠自己的工具。→ 详细
09
API 开放后的意外收获：非工程同事用 SDK 自建 Slack bot 管社媒
- Warp 内部的「有意思现象」：一群非工程岗同事靠 SDK + API 做出各种定制 Slack bot。开发者关系团队搭了一套工具管所有社交媒体提及——推文、Reddit 帖子进来时，agent 接住、做情感分析、理解用户想要什么，再起草一条回复供社媒同事拿去回帖。→ 详细
- 内部还有一大堆类似用法：回答「我们产品是怎么工作的」、做竞品调研等——这些都不是工程师写的，而是把原语开放出去后别人自己长出来的。→ 详细
10
开源三个月：GitHub 星 2 万→6 万+、几千个 PR、数百贡献者
- Warp 从终端长成「agent 式开发环境」后，约三个月前决定开源，「众望所归、期待已久」。结果：GitHub 星数从约 20,000 蹿到 60,000 以上，收到几千个 PR，数百位贡献者——都是平台老用户，终于能在它之上动手构建。这些原语正是在开源时「真正变得至关重要」。→ 详细
11
用 agent 管开源仓库：issue 自动分诊 + agent 先批、人后看的 PR 关卡
- 开源时的设计意图很明确：不要「agent 只写代码、一股脑发 PR」的局面，而是让 agent 实实在在参与仓库的流程结构——分诊 issue、补上下文、做实现、做 review——「但同时仍然给人类留出参与这个循环的空间」。→ 详细
- 现在去 Warp 仓库新开一个 issue（bug 或功能请求），agent 立刻介入自动分诊：在代码库和仓库上下文里调研你到底想提什么；如果描述太抽象，会反过来向你提问要更多信息。她说这正是开源历来最难的活——「有人有个 bug 想修，但给的细节不够，很难推进到需要的清晰度，工作就推不动」。agent 还能帮起草任务的初版规格、做实现。→ 详细
- PR 侧是一道 review 关卡：所有贡献给 Warp 的 PR 都走 agent 管理的 review 流程、多轮迭代，「在 agent 批准 PR 之前，我们根本不会去 ping 团队里任何一位人类 reviewer」。几千个 PR 里，真正要人处理的只剩高信号、高质量的那些。→ 详细
- 配套原则：仓库进来的 PR 越多、看到的代码样例越多，就不断改进这个 review agent——「自我改进的循环是提升整个 SDLC（软件开发生命周期，从需求到上线的整条流程）的一种非常重要的方式」。→ 详细
12
灵光一现：agent 提供「结构和上下文」，让有意图的人都能参与把意图变成实现
- 这套结构化流程能承接大量涌入的 issue 和 PR，带来一个「lightbulb moment」：关键洞察是 agent 提供结构和上下文，意味着「任何人都可以参与进来，把自己的意图转化成实现」。→ 详细
- 为什么重要：「有着真正有意思的意图和目标的人，恰恰是那些把软件用出花样的人，而不一定是写软件的人——是在那个领域里有专业知识的人」。Warp 是开发者给开发者做工具，是个幸运的小众定位；但「大多数软件，都是开发者在给非开发者做工具，或给那些在特定场景下不具备领域专业知识的人做工具」。→ 详细
13
她讨厌「软件工厂」这个词：「人在哪儿呢？」
- 有了结构和护栏，非开发者也能「交付真正像样的软件」，因为支撑的基础设施已经存在。说到这儿她主动碰热词「software factory（软件工厂）」——大家用它谈自动化造软件、提供干活的系统——她「其实挺讨厌这个词」：它没把重点说清楚，而且「人在哪儿呢？」→ 详细
14
陶艺师的工坊：一只马克杯背后的可重复系统
- 她讲了个故事来替换这个词。两个夏天前在农夫市集买了一只马克杯，陶艺师对手艺极有热情，细数杯子的细节：杯柄弧度为不同手型设计、柄顶一个搁大拇指的小凹窝（他眼里的关键人体工学细节）、杯口上沿一层釉让溢出的液体不顺杯壁淌。→ 详细
- 但一问到「工坊有几个陶艺师、做了多少杯子」，他更来劲了：不同部件有不同工位，有专门的采购陶土与备料流程，还给各部件加了验证环节——「如果凹窝尺寸不对，你会怎么办？流程要从哪一步重来？」他的心思不是放在杯子上，而是「工坊如何存在、如何支撑杯子的诞生」，并靠这套系统扩展到几十个学徒、每天手工做出几百只杯子。→ 详细
- 她的提炼：他「打造了一套严肃且可重复的系统，让任何人都能把『一只完美的杯子』这个想法变成一只真实存在的完美杯子」。工坊不是「一个人的古雅工作空间」，而是「重型的干活系统，它是可塑的，会对信号做出反应」——人怎么与正在做的东西互动，它就怎么跟着变；人与工作空间、产出之间是紧密的交互循环。→ 详细
- 综合起来，这才是谈「软件工厂」时真正想要的：给更多构建者（定义正扩展到非开发者）一套把想法变成代码的严肃系统；而长期做开发工具、做软件工程的人，知道这套系统长什么样、该给个人什么支撑。→ 详细
15
把工坊技法翻译成平台原则：响应事件、可观测、自我改进、成本效益
- 她把陶艺师的技法和前面「暴露原语」的方法论对应起来，列出四条：① 自动化响应真实事件——agent 能像工坊里的人应对「窑炉出问题、杯柄断了」一样，对现实世界的事件做出反应；② 可观测——陶艺师会观察大家在他空间里怎么干活再打磨流程，「这不是白来的，你的系统必须真的是可以检查、可以看进去的东西」。→ 详细
- ③ 随时间改进——工作空间不是一成不变的静态组件，要对发生的事做出反应、修正自身去贴合里面干活的人的目标；④ 成本效益——减少另一头出来的「破杯子」/ 有 bug 的软件，且「不牺牲成本、不烧掉太多 token」。→ 详细
- 四条原则的共同目标：「构建那些能把苦活累活（toil and drudgery）从软件流程里去掉的系统，让更多人有能力去构建」。苦活的样子她举了两个：复现一个 bug 的种种困难、监控生产系统的挑战。现在终于能思考这些事的结构，建出可反复、可迁移、能交到非技术岗位的人手里的系统。→ 详细
- 收尾一句：希望大家了解了「正在驱动我们在 agent、开发者和 AI 方面下一阶段工作的工程哲学」。→ 详细
16
闪电问答 / 收尾
本期为大会单人演讲，无闪电问答环节；收尾内容已并入主题十五（四条平台原则与「去掉苦活累活」的共同目标）。→ 详细
17
联系方式
- 线下：AI Engineer 大会 Warp 展位（UG 20），可找 Safia 和团队聊。→ 详细
- 线上：所有社交媒体（GitHub、Twitter 等）统一 ID「Captain Sophia」（ASR 听写，拼写以本人账号为准）；邮箱见其个人网站。→ 详细