跨国深谈← 返回←Warp 如何打造云端智能体平台：把复杂性挡在用户之前

Warp 如何打造云端智能体平台：把复杂性挡在用户之前

关联

人物 Safia Abdalla

公司 Warp

概念 智能体 · 子智能体 · 编排 · 沙箱 · harness · API · 护栏

这一集是 Warp 团队的一场技术演讲，标题叫《幕后智能体》，讲的是他们怎么构建云端智能体平台。主讲人是 Warp 的工程师 Safia（社交媒体账号 CaptainSafia），过去八年一直在做开发者工具：最早在 Jupyter Notebook 核心团队做 Python 和数据科学方向的开源，后来在微软帮 web 开发者构建 API 和 SDK，现在在 Warp 把 AI 智能体搬到云端 。

她开场给出的核心原则只有一条：平台应该在复杂性到达用户之前就把它承担下来。真正好的体验，不应该把内部处理的「泄漏的复杂性」暴露给用户，让他们专注在真正重要的工作上 。

智能体在哪跑：沙箱，托管还是自托管

智能体不在开发者的机器上跑，就得有个地方干活——通常是沙箱，也就是云端一个隔离环境。Warp 最早的方案是提供托管沙箱，开发者不用操心算力在哪，开箱即用 。

但做严肃工作的团队往往自己管理基础设施、有自己的开发机，纯托管方案不够用。所以平台同时支持自托管：让智能体工作负载跑在团队自带的基础设施上，适配他们的安全要求、部署实践和工作流偏好。这套差别被平台抽象掉，用户感知不到 。

用什么 harness：多 harness 支持 + 统一护栏

harness（驱动智能体的框架，如 Claude Code、Codex）是非常个人化的选择，开发者对它有强烈偏好。所以平台做的是多 harness 支持，既照顾偏好，也让人们能为具体任务选合适的工具 。

但灵活性不能硬塞进平台，否则体验会碎片化——用 Claude 和用 Codex、用自定义 harness 的感受完全不同。关键在于平台要围绕 harness 提供结构和护栏，让所有 harness 都能以同样的方式接入平台原生能力：存储并恢复会话状态、与智能体产出的工件交互（PR、issue、新生成的文件），结构全部统一 。

一个智能体不够：编排与 API

真正的工程工作很少能装进一个 prompt 里。典型工作流可能是：一个智能体研究问题、规划方案，另一个负责实现，第三个做验证——而且你可能希望它们用不同的 harness 和模型，形成真正对抗性、稳健的方法 。平台内置了跨技术栈的智能体编排：用户只需一个 prompt 发起「编排」，一个编排者智能体就会在幕后处理与子智能体交互、消息传递、工作跟踪的全部复杂细节 。

更有意思的是通过 API 做同样的事。平台表面的一切都通过 API 暴露：启动智能体和子智能体、管理运行环境和算力、处理产出的工件，全都可以编程调用 。Safia 认为这正是「平台」的关键——优秀 API 和 SDK 的妙处在于人们能在其上构建，不受限于你的 UI 或你对体验应该长什么样的个人看法 。

内部已经长出了不少意外用例：Warp 一批非工程背景的同事用 SDK 和 API 搭了自己的 Slack 机器人。比如开发者关系团队建了一套管理社交媒体提及的工具：推文、Reddit 帖子进来后，智能体会接手、做情感分析、理解用户诉求，然后给社交媒体团队起草一条建议回复 。还有人用它回答产品运作相关的问题、做竞品研究 。

智能体怎么管开源仓库：从 triage 到审查关卡

大约三个月前 Warp 决定开源（从终端成长为智能体开发环境之后），GitHub 星数从约两万飙升到超过六万，收到数千个 PR、数百位贡献者 。

他们不想变成「智能体狂写代码狂发 PR」的局面，而是让智能体有意义地参与到仓库流程里，同时给人类保留参与空间 。现在的实际做法：

• 自动 triage：任何人提交 bug 报告或功能请求，智能体自动启动，在代码库和仓库上下文里做研究来理解诉求；如果觉得原始描述太抽象，还会反问提问者拿更多信息 。这解决了开源历史上最难的一环——报告者细节不足，很难推进到可以动手的清晰度 。
• 规格起草与实现：智能体帮助起草任务的初始规格、做实现。
• 审查关卡：所有贡献到 Warp 的 PR 都经过智能体管理的审查流程，多次迭代；直到智能体批准之前，不会通知任何人类审查者。所以数千个 PR 里，人类真正要处理的只有高信号、高质量的少数 。

关键原则是自我改进循环：随着仓库里 PR 和代码示例越来越多，持续改进智能体，以此增强整个 SDLC（软件开发生命周期）。

由此他们有了顿悟：智能体提供结构和上下文，意味着任何人都能参与把意图转化为实现——而拥有最有趣意图的往往不是构建软件的人，是有领域知识的用户 。大多数软件是开发者为自己没有领域知识的人群构建的；只要提供结构和护栏这些基础设施，非开发者也能交付严肃的软件 。

「软件工厂」这个词，她讨厌

业界流行「软件工厂」的说法，Safia 明确说她其实有点讨厌这个词——「它在哪体现了人？」。她用一个故事讲自己认为更好的类比：

她两年前从一个农夫市集的陶艺师那里买了个马克杯。陶艺师对细节极度讲究：手柄顶部有个放拇指的凹槽，是关键的人体工学细节；杯口上釉，溢出来也不会顺着杯壁淌 。

更打动她的是聊到工作室时对方更兴奋——为杯子的不同部件设不同工位、有专门的黏土采购和预备流程、每个部件都有验证环节（凹槽尺寸不对该重启流程的哪一步？）。这些思考不是放在杯子本身，而是放在工作室如何支撑杯子的创造上，而且扩展到了几十个学徒、每天手工几百个杯子 。

她从中提炼出：真正需要的不是「工厂」，而是严肃的、可重复的、可塑的重型工作系统——它会响应信号、随人们的互动自我调整，并且人和系统之间有紧密的互动回路 。落到工程上就是三件事：

• 对现实事件做反应的自动化：就像陶艺师要对「窑炉失控、把手断裂」做出反应，智能体也要能实现响应现实世界事件的自动化 。
• 可观测性：这不是免费的——系统必须真的可以被检查和深入查看。工作室不是静态组件，它要对正在发生的事做出反应、调整自身，去服务于在其中工作的人的目标和它生产的产品 。
• 成本效益：减少从另一端产出的破损杯子，也就是有 bug 的软件——而且要在不牺牲成本、不过度烧 token 的前提下做到 。

所有这些原则服务于一个共同目标：构建消除软件流程中劳苦与繁重工作的系统，让更多人有能力去构建——复现 bug 的困难、监控生产系统的挑战，这些终于可以被结构化、可重复地做，并且能转移给非技术岗位的人 。

本集带走

• 复杂性平台先扛：托管/自托管沙箱的差异、多 harness 的碎片化风险，都应该被平台结构和护栏吸收，别漏给用户。
• 编排不止一种入口：一个 prompt 让编排者智能体调度子智能体只是表层的；给技术栈每个关键组件（起智能体、管环境、处理工件）都暴露 API，才能让别人在你没想象到的地方构建——Warp 内部非工程师都在用 SDK 搭 Slack 机器人。
• 智能体管开源仓库的正确姿势：不是让它狂发 PR，而是让它做 triage（研究代码库、追问细节）、起草规格、把守审查关卡——智能体批准前不吵人类审查者，人只看高信号的少数。
• PR 越多系统越强：把进来的 PR 和代码示例当反馈源，持续迭代审查智能体，形成自我改进循环。
• 别叫「软件工厂」：更好的心智模型是陶艺师的工作室——严肃、可重复、可观测、会自我调整的工作系统，人在环中，目标是用得起、少出废品，让更多人（包括非开发者）能把意图变成实现。

平台应该在复杂性到达用户之前就把它承担下来。
Platforms should take on complexity before it reaches the user.
—— Safia Abdalla · [03:27]

一个真正好的体验，不应该把它所处理的任何泄漏出来的复杂性暴露给你。
A really good experience should not expose anything of the leaky complexity that it handles to you.
—— Safia Abdalla · [03:31]

我多希望自己只发一个 prompt 就能解决软件里的所有问题，但现实是，真正的工程工作很少能装进一个 prompt 里。
I wish that I could just send off one prompt and solve all of the problems that exist in my software, but the reality is that real engineering work rarely fits inside one prompt.
—— Safia Abdalla · [06:45]

你可能希望这些智能体中的每一个使用不同的 harness 和不同的模型，以便形成真正对抗性且稳健的方法。
And you might want each of these agents to use different harnesses and different models in order to have a real adversarial and robust approach.
—— Safia Abdalla · [07:05]

优秀 API 和 SDK 的妙处在于人们可以在其上构建，这意味着他们不受限于你的 UI，也不受限于你对某个体验应该长什么样的个人看法。
The thing about great APIs and SDKs is people can build on top of them, which means that they’re not restricted to your UI or your opinion of how a particular experience should look.
—— Safia Abdalla · [08:35]

智能体提供结构和上下文这个关键洞察对我们来说非常重要，因为它意味着任何人都可以参与把他们的意图转化为实现。
That key insight of agents providing structure and context was a really big thing for us because it meant that anyone could participate in translating their intent into implementation.
—— Safia Abdalla · [13:38]

拥有最有趣意图的不一定是构建软件的人，而是那个在这个领域拥有领域知识的人。
And it’s not always the person that’s building it. It’s the person who’s kind of got domain knowledge in the space.
—— Safia Abdalla · [13:59]

这个共同的目标就是构建能消除软件流程中劳苦和繁重工作的系统，让更多的人有能力去构建。
And that shared goal is building systems that remove toil and drudgery from our software process so that more people have the ability to build.
—— Safia Abdalla · [19:21]