The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp
频道: AI Engineer
视频: https://www.youtube.com/watch?v=L173Z8DpaJg
原文语言: en
统计: 共 28 轮 · Safia 27
[0:12] Safia
Uh hi, welcome to this session. Uh it is mysteriously titled The Agent Behind the Curtain. Um it's about how the team at Warp built our cloud agent platform. Um before I talk about the how though, I want to talk about the why um and share a little bit about my own background. Um so, I've spent the past 8 years building developer tooling. Um I started off in open source in the Python and data science space um on the Jupiter Notebook core team. I was a maintainer on the Interact project. That work continued in my time at Microsoft helping build APIs and SDKs for web developers. Um and now I'm working on bringing AI AI agents to the cloud at Warp.
呃，大家好，欢迎来到这场分享。它有个有点神秘的标题，叫《幕后的 Agent》。内容是讲 Warp 团队是怎么搭建我们的云端 agent 平台的。不过在讲「怎么做」之前，我想先聊聊「为什么」，顺便介绍一下我自己的背景。我过去 8 年一直在做开发者工具。最早是在开源圈，做 Python 和数据科学方向，在 Jupyter Notebook 核心团队，也是 nteract 项目的维护者。后来在 Microsoft 继续做这类工作，帮着给 Web 开发者构建 API 和 SDK。现在我在 Warp，负责把 AI agent 搬到云端。
[0:59] Safia
And one of the lessons that I've learned in my time building developer tooling is that really good dev tools meet devs where they are and grow with them. Um a tool that you're going to be using every day should accommodate your workflows, but also be really adaptable as the like complexity and the nature of the work changes. And it's important for us to build really great dev tools because dev tools have a compounding effect on the world. If you make a piece of software that helps a developer or a builder do great work, your ability to magnify how much great software exists in the world increases. So, I think it is super important that these dev tools accommodate people's workflows. And people's workflows are important because they love their preferences. You might have a preference for a shell, a language, a harness, a review process.
我做开发者工具这些年学到的一条经验是：真正好的开发工具，会在开发者所在的地方接住他们，并且跟着他们一起成长。一个你每天都在用的工具，应该能适配你的工作流，同时在工作的复杂度和性质发生变化时，也要足够能跟着变。而把开发工具做好这件事很重要，因为开发工具对这个世界有复利效应。如果你做出一个软件，能帮开发者或者创造者把活干得更漂亮，那你放大「世界上好软件总量」的能力就变强了。所以我觉得，这些开发工具能适配人们的工作流，是特别关键的。而工作流之所以重要，是因为大家都很在意自己的偏好。你可能偏爱某个 shell、某种语言、某个 harness、某种 review 流程。
[1:50] Safia
And something that adapts to your workflows and preferences is going to be more enjoyable to use and more enjoyable to build software with. And it also becomes like a part of how you think and build. Um so, it's super important to be attuned to that. And this notion of tools meeting developers where they are and growing with them comes to light really clearly in the progression of AI tooling in this space. So, this is the story for Warp specifically, but it's also the story for a lot of developer tools. Pre-AI era, we had the Warp terminal, which kind of met people in their command-line workflows that they were used to.
一个能顺着你的工作流和偏好走的东西，用起来更舒服，拿它来写软件也更舒服。它还会慢慢变成你思考和构建方式的一部分。所以对这一点保持敏感特别重要。而「工具在开发者所在的地方接住他们、再跟着他们成长」这个理念，在这个领域 AI 工具的演进过程里体现得非常清楚。接下来讲的是 Warp 自己的故事，但它其实也是很多开发者工具的共同故事。在 AI 之前的时代，我们有 Warp 终端，它接住的是大家早已习惯的命令行工作流。
[2:30] Safia
And then this fantastic thing happened where AI got introduced to developers, and now you had a whole new set of tools that was available to you locally on your machine. And a lot of people started to interact with agentic coding patterns in their terminal, in their IDE, in their editor. And then eventually, we realized that we had kind of reached the limits of what we could do on our laptops, and we wanted agents to do work that was more long-running, that was adapted to different constraints, and that work needed to happen in the cloud. Um and whenever you send anything to the cloud, you adopt a lot of complexity um because running things in the cloud requires us to navigate a much messier stack of infrastructure concerns. And when I say we here, I mean the people building developer tools cuz that is the person that I am.
然后发生了一件特别棒的事：AI 走进了开发者的世界，你在本地机器上一下子多了一整套全新的工具。很多人开始在终端里、在 IDE 里、在编辑器里接触 agent 式编程的模式。再往后，我们逐渐意识到，在笔记本电脑上能做的事情差不多到头了——我们希望 agent 去干那些运行时间更长、适配各种不同约束条件的活，而这些活必须放到云上跑。可一旦你把任何东西送上云，就得背上一大堆复杂性，因为在云上跑东西，意味着要在一个混乱得多的基础设施问题栈里摸索。这里说的「我们」，指的是做开发者工具的人，因为我自己就是这样的人。
[3:18] Safia
And it gets at one of the things that are like a core principle in how we think about unlocking capabilities here and building good developer tools is that platforms should take on complexity before it reaches the user. A really good experience should not expose anything of if the leaky complexity that it handles to you. Um when we think about building our cloud agent platform, we try and structure it so that every primitive models this philosophy of hiding complexity from the user so they can focus on the work that matters to them. Um the first place that this shows up when you're building a cloud agent platform is where does the agent run if it's not running on a developer's machine?
这就引出我们思考「如何解锁能力、如何做好开发者工具」的一条核心原则：平台应该在复杂性触达用户之前就把它扛下来。真正好的体验，不应该把它内部处理的那些会「漏出来」的复杂性暴露给你。我们在搭云端 agent 平台的时候，会有意把结构设计成：每一个原语都体现这种「对用户隐藏复杂性」的哲学，让用户能专注在真正对他们重要的工作上。搭建云端 agent 平台时，这件事第一个冒出来的地方就是：如果 agent 不在开发者自己的机器上跑，那它在哪儿跑？
[4:01] Safia
Um, it needs a place to do its work like any developer would and that place is typically a sandbox. It's an isolated environment in the cloud where agents do this task. When we started out building these out for our cloud agent platform, our first intuition was to provide self-hosted sandboxes so that developers had a really easy on-ramp for getting into our cloud agent platform. You didn't have to think about where your compute lived, it was just there for you. But the reality is that for teams doing serious work, they're probably managing their own infrastructure. They probably have dev boxes that they need to interact with and so something that is hosted or managed is usually not sufficient. You really need to be able to run agent workloads on infrastructure that people bring so it adapts to their like security concerns, their deployment practices, their workflows and preferences on their team.
它和任何开发者一样，需要一个干活的地方，而这个地方通常就是 sandbox——云上的一个隔离环境，agent 在里面完成任务。我们最初给云端 agent 平台搭这套东西的时候，第一直觉是提供自托管的 sandbox，让开发者能非常轻松地上手我们的平台。你不用操心算力在哪儿，它就在那儿等你用。但现实是，真正干正经活的团队，多半在管理自己的基础设施。他们可能有自己的 dev box 需要对接，所以纯托管、纯代管的方案通常是不够的。你真的得让 agent 的工作负载跑在用户自带的基础设施上，这样才能适配他们的安全要求、部署实践，以及团队里的工作流和偏好。
[4:51] Safia
And so we add support for not only manage hosting but also self-hosting to the platform and that is complexity that you abstract away from the user and how the behavior is modeled. Um, the next kind of component is a little bit more personal to people and it's the harness that they want to use. As we talked about earlier, people are really passionate about the tools that shape their workflows. Um, one of those tools is the harness. Um, who here has a preference for cloud code as a harness locally? Code X? Something else entirely? Right, so much diversity in the room and we want to meet people where they work.
于是我们在平台上不仅支持托管式部署，也加上了自托管的支持——这又是一层从用户那里抽象掉的复杂性，体现在行为是怎么建模的上。下一个组件就更「私人」一些了：大家想用的 harness。前面说过，人们对塑造自己工作流的工具是很有感情的，harness 就是其中之一。在座有谁本地更偏好用 Claude Code 当 harness 的？Codex 的？还是完全别的东西？对吧，这屋里的口味太多样了，而我们希望在大家工作的地方接住大家。
[5:31] Safia
So you want to integrate multi-harness support that not only accommodates preferences but also gives people the ability to do the use the right tool for the job. And flexibility isn't something that you just be like crammed into a platform because the real risk you run if you cram it in is that it becomes fragmented. Your experience with working with Claude is different from working with Codex versus a custom harness that you might have. And so, one of the key properties is making sure that the platform provides structure and guardrails around the harness so that the experience is consistent. Um for us, this means that harnesses can interact with all of the platform native experiences. So, just being able to store conversation state and rehydrate it, being able to interact with the artifacts and outputs that are produced by agents, whether they're PRs, issues, new files that are generated. All of that should kind of be structured the same way.
所以你会想把多 harness 支持整合进来，不仅照顾偏好，还让人有能力「用对的工具干对的活」。但灵活性不是往平台里硬塞进去就完事的，因为硬塞的真正风险是：体验会碎片化。你用 Claude 的体验、用 Codex 的体验、用你自己定制的 harness 的体验，三者各不相同。所以关键属性之一，就是确保平台在 harness 外面提供结构和护栏，让体验保持一致。对我们来说，这意味着各种 harness 都能接入平台的全部原生能力。比如能存储会话状态并随时恢复，能和 agent 产出的工件与结果打交道——不管是 PR、issue，还是新生成的文件——这些都应该以同一种方式来组织。
[6:26] Safia
Okay, cool. So, we gave you a place for your agent to run, and we gave you a choice for what harness you use, including Warp Zone harness and any other harnesses that you want to bring. Um what if one agent isn't enough to do work? That's the reality of most software engineering. 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. In a typical workflow, you might need one agent to go research a problem and plan a solution. You might need another agent to implement it, and you might need to bring in a third to validate it. And you might want each of these agents to use different harnesses and different models in order to have a real adversar- adversarial and robust approach.
好，很好。到这儿，我们给了你一个让 agent 运行的地方，也让你可以选用什么 harness，包括 Warp 自家的 harness，以及任何你想带来的其他 harness。那如果一个 agent 不够干活呢？这才是大多数软件工程的现实。我也希望只发一个 prompt 就能解决我软件里所有的问题，但现实是，真正的工程工作很少能塞进一个 prompt 里。在典型的工作流里，你可能需要一个 agent 去调研问题、规划方案，需要另一个 agent 去实现，再拉第三个进来做验证。而且你可能希望这几个 agent 各用不同的 harness 和不同的模型，这样才能形成真正「对抗式」的、稳健的做法。
[7:15] Safia
So, we have built-in support for that. You can orchestrate agents across the stack. Um with a lot of agent-based experiences, this orchestration happens via a prompt. So, I say {slash} orchestrate, or I queue the agent via prompting that I want it to delegate work across multiple sub agents for a task that I have here. And this orchestrator agent will do all of the messy complexity of interacting with sub agents, mediating messages between them, and tracking the work that's happening for me behind the scenes with a single prompt. We abstract complexity away from the user by giving them this experience.
所以我们把这个能力内置进来了。你可以跨整个技术栈编排 agent。在很多基于 agent 的产品里，这种编排是通过 prompt 来触发的。比如我输入 /orchestrate，或者通过 prompt 告诉 agent，我希望它把手头这个任务拆给多个 sub-agent 去做。然后这个编排 agent 会替我在幕后处理所有脏活累活：和各个 sub-agent 交互、在它们之间传递消息、跟踪正在进行的工作——全凭一条 prompt。我们就是靠给用户这样的体验，把复杂性从他们那里抽象掉。
[7:53] Safia
This sort of like prompt-based model for interacting with agents and subagents is really powerful. An even more interesting one is the notion of interacting with agents and subagents via the API. So, everything in our surface area is exposed via an API, and I can fire off a request to say that I want to run a subagent that is attached to a parent agent um via configuration that I provide. And this API is super magical because this is the key component of a platform. Um it's exposing the primitives in a way that users can build on top of. Um 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. This is where like composability becomes really powerful.
这种基于 prompt 跟 agent 和 sub-agent 打交道的模式本身就很强大。而更有意思的一种，是通过 API 来跟 agent 和 sub-agent 交互。我们的整个产品表面都通过 API 暴露出来，我可以直接发一个请求，说我要跑一个 sub-agent，并按我给的配置把它挂到某个父 agent 下面。这个 API 特别神奇，因为它是一个平台的关键组成部分——它把原语以一种用户可以在上面继续构建的方式暴露出来。优秀的 API 和 SDK 的意义就在于，别人能在上面搭东西，也就意味着他们不再被你的 UI、或者你对「某种体验该长什么样」的看法所束缚。这正是可组合性变得非常强大的地方。
[8:50] Safia
And so, we're trying to be intentional about exposing an API for every key component of the stack. So, this is APIs for spinning up agents and subagents, for managing the environments and compute that these agents are running in, for working with the artifacts that they produce. All of that is exposed in an API that you can build on top of. Um and this ability to build on top of these primitives that are exposed via an API becomes really useful because anyone can build tools that overlap on top of these agentic experiences.
所以我们在有意识地为技术栈里每一个关键组件都暴露 API。包括：拉起 agent 和 sub-agent 的 API、管理这些 agent 所在的环境和算力的 API、处理它们产出的工件的 API。所有这些都通过 API 开放出来，供你在上面构建。而这种基于 API 暴露的原语往上搭建的能力会变得非常有用，因为任何人都可以在这些 agent 体验之上叠加自己的工具。
[9:25] Safia
[snorts]
（笑声）
[9:25] Safia
Um like interesting phenomena that's happened for us internally is we have a bunch of non-engineering teammates at Warp who have been able to use our SDK and API to build custom Slack bots to do a bunch of things. Um so we have folks in our developer relations team who have actually built out tooling to help us manage all of our social mentions. Um so as tweets and Reddit posts and things are coming in, we have agents that will pick them up, do some sentiment analysis on them, try and understand what the user wants, and then propose a response that um folks on our social media team should use and um respond to the original tweet or Reddit post or what have you. And all of this is enabled by our SDK. And you see like a plethora of these types of experiences um internally at Warp. Um we have people who have used them to help answer queries about how our product is working, do competitive research, all sorts of interesting things.
我们内部就出现了一个挺有意思的现象：Warp 有一群非工程岗的同事，他们靠我们的 SDK 和 API 做出了各种定制的 Slack bot 来干各种事。比如开发者关系团队的同事，真的搭了一套工具来帮我们管理所有的社交媒体提及。当推文、Reddit 帖子之类的内容进来时，会有 agent 把它们接住，做情感分析，试着理解用户想要什么，然后起草一条回复，供社媒团队的同事拿去回原推或者原帖。这一切都是靠我们的 SDK 实现的。在 Warp 内部，你能看到一大堆这类应用。有人用它们来回答「我们的产品是怎么工作的」这类问题，有人用来做竞品调研，各种有意思的用法都有。
[10:24] Safia
Um and these primitives became a really big deal for us specifically when we decided to go open source. Um as I mentioned earlier, Warp started off as a terminal um but it grew into an agentic development environment. And about 3 months ago, we decided to go open source. Um this was like much anticipated, long-awaited. It was a huge success for us. Um the number of like GitHub stars that we had, I think catapulted from around 20,000 to over 60,000. We had thousands of PRs. I'll talk a little bit more about how we've been managing that. And hundreds of contributors who had been long-time users of the platform and were finally getting a chance to build on top of it.
而这些原语真正对我们变得至关重要，是在我们决定开源的时候。前面提到，Warp 最初是个终端，但后来长成了一个 agent 式开发环境。大概三个月前，我们决定开源。这件事可以说是众望所归、期待已久，对我们来说是个巨大的成功。GitHub 星数我记得从大约 2 万一路蹿到了 6 万多。我们收到了几千个 PR——等下我会多讲讲我们是怎么管理这些 PR 的——还有数百位贡献者，他们都是平台的老用户，终于有机会在它之上动手构建了。
[11:11] Safia
And when we went open source, we wanted to be really thoughtful about how we could use agents to help us manage the repository. We didn't want this to be the kind of thing where agents are just writing code and firing off PRs. We want them them to participate kind of meaningfully in the structure that we use to triage issues that came into the repo, provide context around them, do implementation, do reviews, but still have the space for humans to participate in this loop. And we did that. So, if you go to the Warp open-source repo right now, you'll notice that if you file a new issue with a bug report or a feature request, an agent will kick in and start to triage the issue automatically. It'll do research across the code base and context in the repo to understand what you're trying to propose. It might ask you questions if it feels like your original query was a little abstract to get more information, and it will kind of do the work that's historically been very hard for open source, which is somebody has a problem or a bug that they want fixed. They don't give you enough details, and it's hard to get to the clarity that you need to get to to like drive the work forward. So, we can use agents to help us meaningfully in that way. They can also help draft initial specifications and work for tasks, do implementation, and provide a
开源的时候，我们希望认真想清楚怎么用 agent 来帮我们管理这个仓库。我们不想让它变成那种「agent 只是写代码、然后一股脑发 PR」的局面。我们希望 agent 能实实在在地参与到我们那套流程结构里：给进入仓库的 issue 做分诊、补充上下文、做实现、做 review，但同时仍然给人类留出参与这个循环的空间。我们做到了。现在你去 Warp 的开源仓库，会发现只要你新开一个 issue，不管是 bug 报告还是功能请求，就会有一个 agent 介入，自动开始分诊。它会在代码库和仓库上下文里做调研，弄明白你到底想提什么。如果它觉得你原本的描述有点抽象，可能还会反过来向你提问，以获取更多信息。它干的其实是开源社区历来最难搞的那部分活：有人有个问题或者 bug 想修，但给的细节不够，很难推进到你需要的那种清晰度，工作就推不动。所以在这方面，agent 能实实在在地帮上忙。它们还能帮忙起草任务的初版规格和工作内容，做实现，并且提供一道
[12:28] Safia
review gate. So, all PRs that get contributed to Warp go through an agent-managed review process. And it goes through multiple iterations, and we don't actually ping any of the human reviewers on our team until an agent has approved our PRs, um which helps manage the workload a lot for the team. So, all of those thousands of PRs, the things that humans actually have to manage are only the high-signal, high-quality ones. And one of the key principles is that we improve the agent as um we get more PRs in the repo and we see more examples of code. One of the things that we believe is that self-improvement loops are a really important way for you to enhance the overall SDLC life cycle that you're seeing.
review 关卡。所有贡献给 Warp 的 PR 都要经过一套由 agent 管理的 review 流程。它会走多轮迭代，而且在 agent 批准 PR 之前，我们根本不会去 ping 团队里任何一位人类 reviewer——这大大减轻了团队的工作量。所以那几千个 PR 里，真正需要人来处理的只有高信号、高质量的那些。还有一条关键原则是：随着仓库里进来的 PR 越多、我们看到的代码样例越多，我们就不断改进这个 agent。我们相信，自我改进的循环是提升你整个 SDLC 生命周期的一种非常重要的方式。
[13:11] Safia
So, we did this. And we had a lightbulb moment cuz it unlocked something huge. We had this like structured process that could accommodate a big influx of issues and PRs on the repo. Um and the agents were there to support anyone in bringing their idea or their bug request bug feature request or bug report to us or to work and then getting it through to the actual product. That key insight of agents providing like structure and context was a really big thing for us cuz it meant that it could anyone could kind of participate in translating their intent into implementation. And often times the people who have really interesting intents and goals are the ones who are using software in interesting ways. 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. And work we're lucky because we're developers building a developer tool and that's a really unique niche to fill in. But most software is developers building tools for non-developers or people in situations where they don't have domain expertise.
于是我们就这么做了。然后我们有了一个「灵光一现」的时刻，因为这件事解锁了一个特别大的东西：我们有了一套结构化的流程，能够承接仓库上大量涌入的 issue 和 PR。agent 在那里支撑着每一个人，不管是把自己的想法、功能请求还是 bug 报告带到我们这儿、带到 Warp 来，然后一路推进到真正落进产品里。「agent 提供结构和上下文」这个关键洞察对我们来说意义非常大，因为这意味着任何人都可以参与进来，把自己的意图转化成实现。而很多时候，那些有着真正有意思的意图和目标的人，恰恰是那些用软件用出花样的人，而不一定是写软件的人——是在那个领域里有专业知识的人。Warp 很幸运，因为我们是开发者在做一款开发者工具，这是一个非常独特的小众定位。但大多数软件，都是开发者在给非开发者做工具，或者给那些在特定场景下不具备领域专业知识的人做工具。
[14:19] Safia
If we provide these structures and guardrails though, people who are non-developers can have the necessary tools to like ship serious software because the infrastructure to support them exists. Oh, this is where like things get buzzy. You might have heard this term of the software factory. People talk about it a lot as far as like automating how software gets built, providing these systems for doing work, all of these fun things. I kind of want to push back on this term a little bit. I kind of actually hate it cuz I don't think it gets the point across and it feels a little Where's the people in this?
但只要我们提供了这些结构和护栏，非开发者也能拥有必要的工具去交付真正像样的软件，因为支撑他们的基础设施已经存在了。哦，说到这里就开始有点热闹了。你可能听过「软件工厂」这个词，大家经常拿它来谈论如何把软件构建自动化、如何提供这些干活的系统，诸如此类的有趣话题。我想对这个词稍微提一点反对意见。其实我挺讨厌这个词的，因为我觉得它没有把重点说清楚，而且感觉有点……人在哪儿呢？
[15:00] Safia
So I want to tell a story before I share what I think is actually the better word. So this is a mug that I have. I bought this mug about two summers ago from a farmer's market. And I stopped by this booth at the farmer's market and you could just tell the person who had crafted this the potter was just someone who's like really passionate about their work and what they do. And so, he was telling me about all of these interesting details in the mug, the specific like curve of the handle, and the way he had structured it to accommodate different people's hands. He had this like specific dimple at the top of the handle where you could rest your thumb cuz he felt like that was like a key ergonomic detail of this mug. He had this glazing at the top, so if like your cup overflowed, it wouldn't dribble down the sides, the glazing would kind of catch it. So, he just spent so much time thinking about the details of the mug and crafting it.
所以在说出我认为更合适的词之前，我想先讲个故事。这是我的一个马克杯。大概两个夏天前，我在一个农夫市集买了它。我在市集上路过一个摊位，一眼就能看出做这只杯子的陶艺师是一个对自己的手艺和所做的事情充满热情的人。于是他跟我讲起这只杯子里各种有意思的细节：杯柄那个特定的弧度，以及他是怎么设计它来适应不同人的手型的。杯柄顶部有一个专门的小凹窝，可以搁大拇指，因为他觉得那是这只杯子的一个关键人体工学细节。杯口上沿有一层釉，这样如果杯子里的东西溢出来，也不会顺着杯壁往下淌，釉面会把它接住。他就是花了大量的时间去琢磨这只杯子的细节，再把它做出来。
[15:52] Safia
And then I was kind of talking to him about his workshop, like how many potters do you have? How many of these mugs are you making? Yada yada. And he got more even more animated and he started talking about his workshop setup and how he had set up different stations for different components of the mug. He had talked about how he had a specific process for sourcing clay and preparing ahead of time. He talked about how he actually incorporated verification for different components of the mug. If the dimple wasn't the right size, what would you do? What part of the process would you restart? All of this thought that he had put not into the mug itself, but how the workshop existed to support the creation of the mug, and how he was able to scale this to dozens of apprentices in his shop and like hundreds of mugs handcrafted per day, which is pretty impressive.
然后我就跟他聊起了他的工坊，比如你有几个陶艺师？这种杯子你做了多少？诸如此类。结果他更来劲了，开始讲他的工坊是怎么布置的，怎么给杯子的不同部件设置了不同的工位。他讲到自己有一套专门的流程来采购陶土并提前备料。他还讲到自己其实给杯子的不同部件都加入了验证环节：如果凹窝的尺寸不对，你会怎么办？流程要从哪一步重来？他花的这些心思，不是放在杯子本身上，而是放在工坊如何存在、如何支撑杯子的诞生上，以及他是怎么把这套东西扩展到工坊里的几十个学徒、每天手工做出几百只杯子的——这相当了不起。
[16:43] Safia
And this got me thinking, I love what he did with his workshop. Um he had this really great idea and he developed a serious and repeatable system that allowed anyone to take the idea of a perfect mug and turn it into the like actual existence of a perfect mug. You know, some people might think like workshops are this quaint thing where it's like a workspace for a single individual, but I think the story really shows that they're actually heavy-duty systems for doing work and that they're malleable and that they react to signals in how people are interacting with the thing they're building in the space they're building it.
这让我陷入了思考。我很喜欢他对工坊做的事。他有一个非常棒的想法，然后打造了一套严肃且可重复的系统，让任何人都能把「一只完美的杯子」这个想法，变成一只真实存在的完美杯子。你知道，有些人可能觉得工坊是一种古雅的东西，就是一个人的工作空间而已，但我觉得这个故事真正说明的是：工坊其实是一套重型的干活系统，它是可塑的，会对信号做出反应——人们在那个空间里怎么与自己正在做的东西互动，它就怎么跟着变。
[17:21] Safia
Um and it also underscores the like really close interaction loop that humans have with the spaces they work in and the outputs that are produced. And I'm synthesizing all of these ideas and I think this is what really we're driving at when we talk about building software factories. We want to give more builders and the definition of who a builder is is expanding to non-developers serious systems for turning their ideas into code. Um and we as individuals who've been building dev tooling or have been in software engineering for a long time have an understanding of what that serious system looks like and what kind of support it needs to give into individuals.
它还凸显了人与自己的工作空间以及所产出的成果之间那种非常紧密的交互循环。我把这些想法综合起来，我认为这才是我们谈论「建造软件工厂」时真正想要的东西：我们想给更多的构建者——而「构建者」的定义正在扩展到非开发者——一套严肃的系统，把他们的想法变成代码。而我们这些长期做开发工具、或者在软件工程行业里待了很久的人，知道这套严肃的系统长什么样，知道它需要给个人提供什么样的支撑。
[18:00] Safia
Um we break this down into the same techniques that my potter friend had and the same methodologies that I talked about earlier about exposing primitives. Um we expose things like the ability for these agents to implement automations that react to events in the real world the same way that a human in a workspace might need need to react to a real event of you know a kiln um being astray or a handle being broken. We need to make these systems observable. My potter friend talked about how he actually watched the way people worked in his space and refined the process over time. That doesn't come for free. Your system has to actually be something that you can inspect and look into.
我们把它拆解成和我那位陶艺师朋友同样的技法，以及我前面讲过的同样的方法论——暴露原语。我们暴露出这样的能力：让这些 agent 能实现自动化，对真实世界里的事件做出反应，就像一个在工作空间里的人需要对真实事件做出反应一样，比如窑炉出了问题，或者一个杯柄断了。我们需要让这些系统可观测。我那位陶艺师朋友讲过，他其实会观察大家在他的空间里是怎么干活的，然后随着时间不断打磨流程。这不是白来的，你的系统必须真的是可以检查、可以看进去的东西。
[18:43] Safia
And it has to improve over time. The workspace is not the static component that doesn't change ever. It needs to react to what's going on and modify itself to amend to like the goals of the people that are working in it and the product that it's producing. And it needs to be cost-effective. Uh you want to reduce the number of broken mugs that come out the other end. You want to reduce the amount of buggy software that comes out of the other end of your of your factory. Um and you want to do this without compromising on cost without spending too many tokens. All of these principles work to achieve a shared goal 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. We've seen the way like toil and drudgery have manifested. It could be all of the difficulty you might have reproducing a bug, the challenges of monitoring a production system. Those are things that are really hard to do.
而且它必须随时间不断改进。工作空间不是一个一成不变的静态组件，它需要对正在发生的事情做出反应，并修正自身，去贴合在里面干活的人的目标以及它所产出的产品。它还需要有成本效益。你想减少从另一头出来的破杯子的数量，你想减少从你的工厂另一头出来的有 bug 的软件，而且你想在不牺牲成本、不烧掉太多 token 的前提下做到这一点。所有这些原则都服务于一个共同的目标：构建那些能把苦活累活从我们的软件流程里去掉的系统，让更多人有能力去构建。我们已经见识过这些苦活累活是怎么体现出来的：可能是你复现一个 bug 时遇到的种种困难，可能是监控生产系统的挑战。这些都是非常难做的事情。
[19:44] Safia
And we can finally start to think about the structure of how we do them and building systems that allow us to do them repeatedly and transferably to people who are in non-technical roles. If these ideas excite you about how we can build these robust and reliable systems for anyone to ship software, you could stop by the Warp booth to come talk to me and the crew. We're at UG 20. You can also mention me on Twitter. I'm Captain Sophia on all social media, GitHub, Twitter, all of that fun stuff. Or just drop me an email. You can find my email on my personal site. Thanks for coming to this presentation.
而我们终于可以开始思考做这些事情的结构了，去构建那些让我们能够反复地、可迁移地做这些事的系统，并把它们交到非技术岗位的人手里。如果这些想法让你感到兴奋——关于我们如何构建这些稳健可靠的系统，让任何人都能交付软件——欢迎来 Warp 的展位找我和团队聊聊，我们在 UG 20。你也可以在 Twitter 上 @ 我，我在所有社交媒体上都叫 Captain Sophia，GitHub、Twitter，都是这个名字。或者直接给我发邮件，我的邮箱在我的个人网站上能找到。感谢大家来听这场演讲。
[20:21] Safia
I hope you learned something interesting about some of the engineering philosophies that are driving the next set of work we do as far as agents, developers, and AI.
希望你从中了解到了一些有意思的东西——关于那些正在驱动我们在 agent、开发者和 AI 方面下一阶段工作的工程哲学。
[20:32]
[applause]
（掌声）