Ep 59. 2026 Agent 编程新趋势

概览

本期围绕 AI 编程工具的演进展开，主播和嘉宾小 A 从自身工作流出发，讨论工程师从手写代码转向大量依赖 AI 写代码之后，工具形态、交互方式和团队协作方式发生的变化。

节目把 AI 编程工具的发展分成两个阶段：第一阶段是 2023 到 2025 年前后出现的“在传统编辑器或 CLI 上加 AI”的过渡形态；第二阶段则是以 Agent 为中心的 AI Native 工作流，包括 AI Coworker 和 Agent 指令中心。

核心结论是，Codex、Cursor、Anti-Gravity 等新一代工具正在弱化“人直接看代码、改代码”的中心地位，把用户旅程转向“给 Agent 下指令、审查结果、反馈迭代”。但这种趋势也带来新的问题：Agent Harness、主动式 AI、团队协作和可验证性仍是未来产品需要重点突破的方向。

分段落总结

[00:19] 开场与使用现状

[事实] 主播 Light9M 介绍本期是关于 AI 编程工具趋势的讨论，并邀请某大厂 AI 产品组工程师小 A 参与。

[事实] 小 A 表示自己现在手写代码的情况非常少，大部分时间都使用 AI 写代码。

[事实] 小 A 提到公司内部会使用 Code API、最新模型，以及内部 context、skills、MCP、plugin 等能力来构建 Coding Agent 工作流。

[事实] 主播也提到自己在 Google 做 Coding Agent，并表示内部大部分时候也使用 AI 写代码。

[02:24] 第一阶段：传统编辑器与 CLI 上的 AI 编程

[事实] 主播把 2023 到 2025 年左右称为“从手写代码到 AI 写代码”的阶段。

[事实] 这一阶段的代表形态包括 VS Code 加 AI 聊天侧边栏、早期 Cursor，以及命令行里的 AI Agent 工具。

[事实] 主播认为这一阶段的产品主要是在已有开发工具上叠加 AI 能力，因为当时大家还不清楚 AI Native 或 Agent Native 的编程方式应该是什么样。

[事实] 主播说明，CLI 形态虽然现在仍然主流，但它属于早期出现的产品形态，并不代表它已经没人使用。

[推测] 主播把 CLI 和侧边栏式工具称为过渡阶段，是因为它们仍以传统人类编程界面为中心，而不是以 Agent 工作流为中心。

[04:49] 第二阶段：AI Coworker 与聊天式协作

[事实] 主播把从 2025 年下半段开始出现的一类产品称为 AI Native 工作流。

[事实] 其中一类是 AI Coworker 协作软件，本质上像聊天应用，用户可以在聊天中 @Agent 完成不同任务。

[事实] 主播将这类产品类比为 Slack，只是其中一部分“成员”不再是员工，而是 Agent。

[事实] 主播认为搭载在 IM 或聊天软件里的 Agent 协作，是一种非常 AI Native 的工作流。

[05:36] Agent 指令中心成为新产品形态

[事实] 主播提出另一类 2026 年左右出现的形态，称为 Agent 指令中心。

[事实] 主播以 Cursor 3 为例，说明它重写了原来基于 VS Code 的界面，把左侧从文件列表改成 Agent 会话列表，把中间主体改成与 Agent 的对话。

[事实] 在这种界面里，用户完成一轮对话后，可以通过对话中的代码链接在右侧查看修改，并进行手动修改或反馈。

[事实] 主播认为这个变化不只是 UI 改动，而是从“以人写代码为中心”转向“以 Agent 对话为中心”。

[推测] Agent 指令中心降低了用户必须直接阅读和书写代码的程度，也改变了软件开发的入口。

[07:24] Agent 优先界面的优势与代价

[事实] 小 A 指出 Codex、Anti-Gravity 2.0 和 Cursor 3 的界面模式很相似，都是 Agent 优先的新一代编辑器。

[事实] 小 A 认为这类工具弱化了看代码的功能，因此在仍然需要频繁回到代码细节的开发场景中，可能不如传统 VS Code 式编辑器适配。

[事实] 小 A 认为 Codex 试图打破 Coder 和 Software Builder 的界限，让 PM、Designer 等非传统程序员也能成为 Software Builder。

[事实] 主播认为，如果仍需逐行阅读代码，传统编辑器会更好；但趋势可能是不再必须读每一行代码。

[推测] 多家 AI Coding 头部产品趋同到类似界面，说明 Agent 指令中心短期内可能会成为主流模式。

[10:08] 未来演进的四个方向

[事实] 主播提出 AI 编程工具后续有四个值得关注的演进方向。

[事实] 第一是更好的 Agent Harness，也就是让 Agent 的运行框架和能力组合变得更强。

[事实] 第二是主动式 AI，让 Agent 不只是听从指令，也能主动提出改进建议。

[事实] 第三是 AI Agent Native 下的团队协作，尤其是多人同时用 Agent 快速提交代码后产生的上下文割裂问题。

[事实] 第四是可验证性，也就是如何确认 Agent 的代码修改真正有效并完成了用户目标。

[12:21] Agent Harness：上下文、记忆、沙箱与技能管理

[事实] 主播认为 context 是 Agent Harness 中最头疼的问题之一，因为上下文过大容易超过模型窗口。

[事实] 常见做法包括 compaction，把长对话压缩总结后再给模型，但这种方式会造成信息丢失。

[事实] memory 机制用于让 Agent 记住重要信息，Dynamic Context 则尝试每次只提供部分内容，或让 Agent 自己探索所需文件。

[事实] 主播还提到安全沙箱、记忆生命周期管理、skill 生命周期管理等都是热门方向。

[推测] 更好的 Harness 不只是“包一层工具”，而是在控制信息、执行环境和长期知识之间做系统设计。

[14:30] Subagents 与动态工作流

[事实] 主播提到 subagents 是过去一年很热门的领域，并举例说有些团队喜欢构建由不同角色组成的 Agent Team。

[事实] 小 A 提问，同样是 PM 角色，是否能根据需要呈现严谨型、创造型等不同特质。

[事实] 主播回应说，Anthropic 最近的 dynamic workflow 会根据任务自动创建合适的 Agent Team 组合，例如 leader、worker、verifier 等不同结构。

[事实] 主播认为，从写 skill 到重新强调多个 agent，反映了 Agent Harness 设计会随模型能力和训练数据变化而循环演进。

[推测] 当前多 Agent 流程仍需要 Harness 层显式组织，未来如果模型具备更多相关训练数据，Harness 可能会变薄。

[17:43] Harness 与模型训练的反馈循环

[事实] 小 A 提到一种观点：许多 Harness 层能力未来可能被放进 pre-training 中。

[事实] 小 A 认为，Coding Agent 厂商会先把新需求做进 Harness 层，通过用户使用产生数据，再反过来改进 Harness 设计和模型训练。

[事实] 主播同意这类似一个 feedback loop：更多用户数据能帮助模型训练得更好。

[事实] 主播也声明自己不是大模型 training 专家，如果听众认为这里有问题，欢迎交流指出。

[推测] 这一段的讨论说明，产品层和模型层不是割裂的，Agent 产品使用数据可能会持续影响模型能力边界。

[18:59] 主动式 AI：从建议到自动 PR

[事实] 主播介绍自己团队的 Juice Coding Agent 会扫描代码库，查找 todo 或性能瓶颈，并生成建议。

[事实] Juice 会通过邮件发送建议，用户确认后，它可以创建 GitHub pull request。

[事实] 主播表示自己已经合并了不少来自 Juice 的 PR，并认为主动式 AI 会成为未来方向。

[事实] 主播认为维护类任务很适合由 Agent 主动完成，例如修复 linting、创建简单单元测试、升级依赖、修复安全漏洞等。

[事实] 主播还提到，把 GitHub issue 或 Jira ticket 自动转成 prompt，再交给 Agent 完成，也是已有实践。

[21:10] 主动式 AI 的边界：创造性与噪音

[事实] 小 A 指出，当前所谓主动式 AI 很多并不是真正创造新 workflow，而是把人类已经发现的可行 workflow 抽象、标准化并集成成一键流程。

[事实] 主播认为未来值得探索的是 Agent 能否真正做创造性修改，例如在没有明确外部输入时主动添加新 feature。

[事实] 小 A 提到，如果加上 validator，就可以用这类系统做 A/B test。

[事实] 主播认为目前更常见的是用户设置高层目标，例如提高转化率，然后 AI 基于该目标提交修改。

[推测] 完全不依赖外部输入的主动产品修改目前仍不成熟，主要风险是噪音大、浪费 token，以及产出不符合用户意图。

[22:54] 团队协作：Agent 带来的上下文割裂

[事实] 主播认为，当团队所有工程师都使用 Agent，代码提交量可能达到过去的很多倍，从而放大冲突和协作问题。

[事实] 这些问题包括不同人修改数据库 schema 或设计决策时互相不知道，以及各自 Agent 的 memory 不共享。

[事实] 主播提出 team memory 层的想法，把每个人的记忆汇总起来，让 Agent 可以访问同事 Agent 的相关记忆。

[事实] 主播提到 Sage Ox 这家公司会把团队会议录音转写，再由 Agent 提炼成 memory，用于后续任务。

[事实] 主播表示自己在内部大量使用 Agent 开发产品时，已经遇到同事修改间接破坏自己测试的情况。

[25:10] Team Workspace 与 IM 上下文

[事实] 小 A 提到一种简单方案是在 Codex 这类工具中建立 team workspace，让所有 Agent 运行在云端并共享记忆。

[事实] 主播认为这种方式可以解决一部分问题，因为所有人的 Agent 对话对其他人可见。

[事实] 主播也指出，并不是所有人都想把所有工作放进 team workspace，记忆提取还会带来隐私和信噪比问题。

[事实] 主播引用 Graft 团队的观点，认为即时聊天软件非常适合收集上下文，也是让上下文增长的自然界面。

[事实] 主播认为 AI Coworker 这类聊天软件天然共享上下文，但缺少编辑器本身的功能；如果能结合两者会更好。

[27:36] 可验证性决定 Agent 上限

[事实] 主播指出，许多 Coding Agent 现在最后一步都会做简单验证，例如启动本地 server、发送 HTTP 请求、检查返回值。

[事实] 如果验证失败，Agent 会尝试修复并继续循环，直到测试通过。

[事实] 主播认为验证问题尚未解决，最大瓶颈是测试环境搭建，尤其是前端、浏览器自动化、截图评估、视频录制或 Android 工具链等复杂场景。

[事实] 远程沙箱是一种常见解决方案，可以预装团队项目所需依赖，但很难做成完全通用的 Agent 环境。

[事实] 主播引用前老板的观点：如果 Agent 能验证自己的工作是否完成任务，它基本上就可以做任何事情。

[推测] 可验证性是 Agent 能否从“辅助写代码”走向“完成复杂任务”的关键能力。

[30:23] 先搭建验证系统再让 Agent 工作

[事实] 小 A 补充说，使用 Agent 做一些后端工作时，第一步不一定是直接开工，而是先搭建验证系统。

[事实] 小 A 认为，在验证模型比较清晰的任务里，应先把验证做好，再让 Agent 开始执行其他工作。

[事实] 小 A 也指出，这种做法并不适合所有工作，因为有些任务一开始并没有清晰的验证模型。

[事实] 节目最后，主播邀请听众阅读相关文章，小 A 也请听众点赞、转发和留言。

播客点评/总结

这期的价值在于，它没有只停留在“AI 写代码更快”这个表层结论，而是把 AI 编程工具的产品形态、交互中心和工程组织方式串起来讨论。尤其是从传统编辑器、CLI 到 Agent 指令中心的划分，能帮助听众理解为什么新工具看起来越来越不像传统 IDE。

亮点是讨论覆盖了工具界面、Agent Harness、主动式 AI、团队记忆和验证系统等多个层次，并且结合了主播和嘉宾在真实工作中的使用经验。节目中对 team memory、IM 上下文和可验证性的讨论，尤其适合已经在团队里重度使用 Coding Agent 的工程师或产品负责人。

[推测] 局限在于，部分产品名、模型名和公司实践来自口头转录，信息细节可能不够精确；另外节目主要是趋势判断和经验分享，没有展开具体产品对比、实测数据或落地架构。

[推测] 本期最适合关注 AI Coding 工具、Agent 产品设计、工程团队效率和开发者工具创业方向的听众；如果听众只想获得某个具体工具的使用教程，这期更像宏观分析而不是操作指南。