最近我越来越觉得，AI 编程已经不只是“写代码更快”这件事了。它正在把软件开发往另一个方向推：人不再主要亲手敲代码，而是开始搭建上下文、制定边界、分配风险，并同时管理一群会干活的代理。
这篇文章整理自 Spotify 和 Anthropic 的一场现场对谈，题目是《Let’s Talk Agentic Development》。两边聊的不是炫技演示，而是他们内部已经发生的工作方式变化：工程师从 IDE 切到终端，多代理并行开始常态化，MCP 从“新协议”变成组织级连接层，原来的开发瓶颈也从写代码转向 CI、代码评审、上下文治理和责任划分。原视频：https://www.youtube.com/watch?v=fHDGQHr_agg
从 IDE 到终端，不只是界面迁移
对谈里最有意思的一段，是他们都提到一个很具体的变化：团队里的人突然不再盯着 IDE，而是开始长期盯着终端，让 Claude Code 在多个 pane 里同时跑。
Anthropic 的 Christian 回忆，Opus 4.5 刚出来时，他一开始其实没那么震撼。因为他看到的首先是一些边角问题：模型有点固执，喜欢乱用 bash，不太愿意老老实实走产品里给的工具接口，团队花了不少时间做 prompt 和工具适配。但后来他看到一个 demo：Claude 几乎从零一把做出了 Claude.ai 的界面和 artifacts 功能，而且能连续跑几个小时。这时候他才意识到，自己之前盯着局部 bug，看不到模型能力已经跨过了一个台阶。
Spotify 那边的感受更直白。他们内部能在图表上看到某个模型版本发布之后，开发者的 AI 使用量明显拐头向上。更重要的不是“多了一点使用”，而是工作姿势变了：过去做复杂任务，人还得不停在旁边扶着模型，随时把它拉回正轨；后来开始可以同时放六七个、甚至十个 Claude 在不同 worktree 里各做各的事，人只在最后统一看结果。
这里真正变化的不是编辑器，而是人和代码之间的关系。IDE 时代，默认前提是“人写，工具辅助”；agent 时代，越来越像“agent 生产，人验收”。终端只是更适合这种工作流：它天然支持并行、脚本、命令组合、长时间运行，也更接近模型最擅长调用的环境。
所以，别把“从 IDE 切到终端”理解成开发者审美变了。它更像一个信号：当模型的长程执行能力、工具调用能力和容错性跨过某个阈值之后，人的位置就会从操作者变成调度者。
MCP 为什么会这么快爆发
MCP 这几年已经被谈得很多，但这场对谈里 David 讲得很实在。他没有把 MCP 说成万能钥匙，而是把它放回一个很具体的历史时点里：模型开始真正擅长用工具，可开发者手里还没有一套通用、标准、可扩展的连接办法。
他认为 MCP 爆发，至少有几个原因。
第一，它来自大模型实验室。协议要形成生态，技术本身当然重要，但来源也重要。一个大实验室推出的协议，天然就更容易获得注意力、信任和初始采用。
第二，它踩中了时间点。那时像 Sonnet 3.5 这样的模型已经让大家明显意识到，工具使用不是附属功能，而是 agent 能力的基础层。问题不再是“模型能不能回答问题”，而是“模型怎么连接外部世界”。MCP 正好填上这个缺口。
第三，它借鉴了成熟协议的经验。David 直接说，他们大量参考了 LSP，也就是 Language Server Protocol。这个思路很对：协议创新不一定要从零发明语法，很多时候更重要的是抓住抽象边界，让两侧系统可以独立演化。
但他也讲了 MCP 现在最难的地方。不是功能，而是企业化补课。传统互联网协议有几十年时间慢慢打磨认证、身份、代理、企业治理，而 AI 协议没有这个奢侈条件。协议刚一出圈，就得同时面对安全、权限、审计和大规模接入问题。
所以他给了一个很清楚的使用边界：
- 本地 coding agent 场景下，CLI 往往已经很好用，甚至是最优解；
- 一旦进入企业远程集成、知识工作者接系统、需要统一鉴权和中间网关的场景，协议就比裸 CLI 更合适。
这个区分很关键。很多人一谈 MCP，就像在问“未来是不是所有工具都该变成 MCP”。其实不是。它解决的是跨系统、跨团队、跨信任边界的连接问题，而不是取代一切本地工具。
上下文工程没有消失，但重心变了
对谈里还有一条很值得注意的线索：他们都承认，上下文仍然重要，但“怎么给上下文”这件事正在变化。
Spotify 提出一个三层模型，我觉得很有启发。
第一层，是离模型最近的执行层上下文，比如 Claude.md、skills、局部规则、仓库说明。这一层直接影响 agent 怎么在具体代码库里做事。
第二层，是公司层面的高层上下文，比如业务优先级、战略方向、组织目标。这些东西通常存在文档里，但不会天然进入模型的工作流。
第三层，是中间那层最难的东西：怎么把公司的战略、产品流程、PRD、规划文档，一路接到最后的代码实现上。
Spotify 说，他们对第一层已经做得不错了，真正还没完全打通的是中间层。这个判断很诚实，也很准确。很多团队今天谈“上下文工程”，本质上还停留在第一层：写更好的 prompt、整理更好的 repo 说明、做一些知识库接入。但真正难的，不是把局部代码知识喂给模型，而是让组织的意图顺着一条稳定链路流到 agent 手里。
Anthropic 这边的态度则更偏向“少手把手，多给基础设施”。Christian 提到，他越来越觉得，试图在上下文里把模型管得太细，价值会快速折旧。因为模型能力更新太快，很多你今天精心写下的限制、路径指令和技巧，过几个月可能就变成多余的扶手。
他现在更相信的是几类东西：
- 好用的工具人体工学，也就是 agent 容易理解和调用的 CLIs、MCP servers；
- 可重复的验证循环，比如测试、lint、质量门禁；
- 让 agent 自己去查知识库的能力，而不是要求人类预先把答案塞满上下文。
这其实是在重新分配“聪明”应该放在哪里。以前大家爱把聪明放进 prompt，现在更合理的做法，是把聪明放进工具设计、知识可检索性和反馈回路里。
标准化不是为了管人，而是为了让 agent 能跑起来
Spotify 很早就在做标准化。他们内部用过一个很有意思的说法，叫 golden technologies，本质上就是公司级标准栈。后来又做了 fleet management，用自动化手段管理成千上万个软件组件的变更。
在没有 LLM 的时代，这种标准化已经有价值；到了 agent 时代，它的价值反而变得更高。
原因很简单。人可以在一个混乱系统里靠经验硬撑，agent 不行。agent 要想稳定工作，需要默认路径、统一接口、清晰边界和可预期反馈。标准化越强，agent 的表现通常越稳；系统越碎，agent 越容易在环境差异里浪费上下文窗口和试错次数。
Anthropic 的实践也印证了这一点。他们提到，在 monorepo 里启动 Claude Code 时，默认就会带着合适的 Claude 配置、预置的 skills，以及能直接连上的内部知识和系统。也就是说，一个新成员打开环境时，好的默认值已经在那里，不需要每个人从零搭一套。
这类标准化过去常被理解为“平台团队为了治理方便”，现在更应该理解为“给 agent 铺轨道”。轨道铺得越好，组织内部越容易把个人经验沉淀成集体能力。
真正的组织变化，是非开发者开始直接下场
这场对谈不只是讲开发者提效。它反复提到一个更深的变化：非开发者也开始进入软件生产流程。
Spotify 内部的 Honk，最开始是为了做大规模代码迁移，比如批量把某个 API 版本迁到另一个版本。这件事以前常用 codemod 或其他确定性脚本做，但复杂度一上去，很快撞到天花板。于是他们开始尝试用 LLM 做这类 fleet-wide change，最后逐渐做成了 Honk 这个内部工具。
但工具一旦做出来，使用场景就迅速外溢。现在内部一个典型用法是：人们在 Slack 里讨论某个问题，直接 @Honk，让它去解决。这个动作把“发起一次软件变更”的门槛压得很低，也让不熟悉本地开发环境的人能直接调起代理干活。
Spotify 还提到一个很说明问题的方向：以后某些原型工作的最终产物，未必是 PR，而可能是一整个可以安装到手机上的 app 版本。也就是说，设计师、PM，甚至不写代码的人，不再必须穿过开发者那整套本地构建和 PR 流程，才能验证一个想法。
这件事的后劲很大。
当软件生产能力从“千名开发者的专属技能”变成“更多知识工作者都能调动的组织能力”时，团队结构、平台职责、权限系统、责任边界都会被重写。你服务的就不再只是工程师，而是五倍、十倍于工程师规模的内部用户。
原型驱动会进一步吞掉 PRD 驱动
Anthropic 讲他们内部文化时，说了一句很有代表性的话：code wins arguments。以前这句话就存在，现在代码变便宜了，这句话更成立。
他们提到，很多产品并不是先有完整 PRD，再照着做，而是先做出原型，在内部找使用黏性，再决定要不要继续推。Christian 甚至把内部使用描述成一种“内部市场”：大家会看某个工具有没有日活、留存、粘性。如果内部都没人爱用，它大概率也不值得往外推。
这其实解释了为什么今天很多 AI 产品看起来像突然冒出来。不是因为想法突然出现，而是因为组织内部已经有足够低的试错成本，可以同时并行孵化很多原型，把真正有内部 PMF 的那批留下来。
Spotify 也有类似倾向。他们提到，以后可能会越来越少写抽象 PRD，而是更快拿一个可运行 demo 出来，让团队直接讨论“是不是这个东西”。当原型生成速度快到足够低成本时，文档的作用不会消失，但它会越来越像补充说明，而不是唯一入口。
新瓶颈已经出现：CI、评审、责任归属
如果说过去的软件组织长期受限于“代码写得太慢”，那现在瓶颈正在往后移。
Anthropic 和 Spotify 都明确提到，他们已经感受到下游压力：
- CI 变得更容易过载；
- 代码评审压力上升；
- 需要更强的静态分析和 lint；
- 当代理产出大量 PR 时，谁来最终负责，变得更重要。
这一段特别值得细看。因为很多关于 agentic development 的讨论，还停留在“能不能生成代码”。这其实已经不是核心问题了。真正难的是：当组织每天能生成远多于过去的改动量之后，验证、审批、回滚、审计和责任机制是否还能跟上。
Anthropic 的回答很务实。他们承认这还是个未完全解决的问题。可以用更多子代理做验证、用更强的 CI、用本地 review、用更严格的测试来缓解，但最后仍然需要有人对结果负责。谁批准，谁担责，这个机制不能被代理稀释掉。
Spotify 则补了一层很重要的视角：风险分级。不同系统的改动，不该用同一套 assurance 流程。关键基础设施、核心生产链路，仍然需要更重的人类判断；前端产品区、可灰度、可 feature flag 的地方，则可以更快迭代。
这说明 agent 时代并不会消灭治理，而是要求治理更细。以前你可能只需要区分“线上”和“非线上”，以后更像要为不同可靠性等级、不同回滚成本、不同爆炸半径设计不同的代理工作流。
下一阶段不是生成更多代码，而是接管更完整的软件生命周期
对谈快结束时，David 提到一个我很认同的判断：过去一年，行业主要把注意力放在“代码生成”上，但真正还没充分展开的，是软件生命周期的后半段。
软件不只是被写出来。它还要被维护、被调试、被升级、被删除。模型如果只能生成新代码，却不能持续承担维护和清理工作，整体系统很快就会变得不可持续。
这个判断很重要，因为它把 agent 的角色从“生成器”往“维护者”推进了一步。下一阶段更值得看的，不只是哪个模型能一把写出更多 feature，而是谁能把测试、回归、重构、删除废弃代码、排查部署问题、运营系统健康这些环节真正接起来。
这也会重新定义内部开发平台。Spotify 说得很直白：像 Backstage 这样的工具，正在从“人直接操作的后台”变成“agent 通过 MCP 调用的系统层”。以前工程师进入 Backstage 查部署、看服务、排故障；现在这些动作开始由 agent 去做，人只看结果。
这一步一旦成立，很多平台产品都要重写接口思维。你面对的主要用户，不再是会点按钮的人，而是会调用 API、会走协议、会受权限约束的代理。
我的补充：组织正在进入“代理管理”阶段
如果把这场对谈压缩成一句话，我会说：AI 编程的重点，已经从“让模型会写代码”转向“让组织能容纳大量代理稳定工作”。
这两个阶段差别很大。
第一阶段拼的是模型、prompt、局部技巧和个人效率；第二阶段拼的是默认上下文、标准化、工具接口、验证闭环、权限体系和责任归属。前者更像个人生产力革命，后者才是真正的组织工程。
也是因为这个原因，我现在越来越觉得，很多团队讨论 agentic development 时容易把注意力放错地方。大家会花很多时间争论某个 prompt 写法、某个 MCP server、某个 skill 模板是不是最优，但这些东西都只是局部杠杆。真正决定天花板的，还是组织有没有把下面这些东西搭起来：
- 能不能让 agent 容易找到知识，而不是靠人喂；
- 能不能让默认环境足够一致，而不是每个人各搭一套；
- 能不能把风险分层，而不是所有改动都走同一条线；
- 能不能让非开发者安全地下场，而不是永远卡在开发入口；
- 能不能把“谁负责”说清楚，而不是出了问题才追人。
如果这些问题没解决，agent 只会把旧流程里的混乱放大；如果这些问题解决了，代理才会从“炫技工具”变成真正的组织能力。
这也是我看完这场对谈后最强的感受：2025 年以后，最值得看的不再只是哪个模型更强，而是哪家公司最先把“代理如何进入组织”这件事做成一套长期机制。
就这些。