每周 Signal

这一周，GPT-5.5 和 DeepSeek V4 先后出现，表面看仍然是熟悉的模型竞赛：更强的代码能力、更长的上下文、更低的成本、更好的 Agent 适配。

但另一个变化也越来越明显：模型能力当然还在提升，却很难再像早期那样，仅靠一次模型发布就重新定义所有人的使用体验。真正决定 AI Coding 能不能进入研发现场的，正在变成另一组问题：模型是否能稳定接入工具，是否能消化足够上下文，是否能持续执行任务，是否能进入评审、验证和组织流程。

换句话说，模型仍然是底座，但不再是唯一主角。

AI Coding 的竞争，正在从“谁的模型更强”，逐渐转向“谁能把模型组织成一个可持续运行的研发系统”。

过去我们用 AI Coding，很多时候还是一种很熟悉的形态：
开一个窗口，盯着一个 Agent，一来一回把事情做完。

但最近一个更具体的变化是，前沿工具开始不再默认你只和一个 Agent 协作。
OpenAI 的 Codex app、VS Code Agents，以及 GitHub Copilot CLI 的 /fleet，都开始把“并行开多个 Agent session”做成产品里的标准能力。

这背后其实不是多了一个功能点，而是工作单元在变。
以前更像是：我和一个 Agent 来回协作。
现在开始变成：我同时放出几个 Agent，让它们分别研究、实现、检查，再由我回到更高一层做判断和收敛。

也就是说，AI Coding 正在慢慢从“单次对话”，走向“并行推进中的多个任务线程”。

过去一段时间，大家讨论 AI Coding，注意力大多还放在 Agent 本身：会不会拆任务、能不能把需求一路推进到可提交状态、出码率高不高。
但最近一个越来越明显的变化是，前沿工具建设者开始更关注另一层问题：什么样的系统，才能支撑 Agent 稳定把任务做完。

从 Harness、Managed Agents，到长时任务执行、状态持续、验证机制，这些话题最近不断出现，背后其实都指向同一件事：
当 Agent 开始承担更长链路的研发任务，差距开始不只在模型能力上，也在于有没有一套系统，能把任务表达、执行推进与结果校验组织起来。

收敛一点说：
前沿 AI Coding 的竞争，正在从“谁的 Agent 更能做”，转向“谁的系统更能支撑 Agent 稳定做完”。

最近有一个感觉越来越明显。

过去我们看代码仓库，更多会把它理解成实现载体。
页面、接口、状态管理、权限判断、校验逻辑、异常处理，都是为了把功能做出来，也主要服务于人理解和维护系统。

但当 AI 开始读仓库、补上下文、参与生成、调用和编排时，仓库里另一层东西也开始变得更重要：
系统里有哪些业务对象，状态怎么流转，规则和约束在哪里，一件事情要经过哪些路径才能完成。

这些东西过去当然一直就在仓库里，只是更多服务于人理解。
而现在，它们也开始成为 AI 理解业务如何在系统中被组织和完成的基础。

这可能意味着，代码仓库的价值，正在从“存放实现”延伸到“成为业务结构的来源”。

过去的软件中，界面是操作入口。
用户通过点击、输入来触发功能，执行由人驱动。

但随着 Agent 开始参与执行，这一结构正在改变。

执行开始从“被触发”，走向“持续运行”。

在这个过程中：

• CLI 的流行，本质是执行入口的压缩
• GUI 不再承担主要操作职责，而逐渐转向系统状态的观测与干预
• 在真实需求中，问题已经不再是“AI 能不能写”，而是“系统能不能稳定执行”

当执行可以持续运行之后，
软件也开始发生变化。

它不再只是被使用，
而开始被运行。

过去的软件研发中，复杂问题主要由人来承载：
系统设计、边界划分、异常处理，往往依赖经验更丰富的个体。
复杂度集中在少数人身上，也构成了组织中的关键节点。

但随着 AI 参与需求理解、任务拆解、代码生成与验证，原本由人承担的复杂度，正在被逐步外化为结构化表达，并交由系统处理。

执行复杂度，正在从人迁移到系统。

系统一旦开始接管这部分复杂度，原有基于经验和理解建立起来的能力边界，也会随之被重新定义。
变化并不首先体现在执行效率，而是体现在承载复杂度的位置发生了转移。

新的分界线也随之出现：
不再是谁更会做，而是谁能把问题转化为系统，并让系统稳定运行。

当执行复杂度被系统接管后，系统复杂度开始变得更清晰，也更关键。

最近在关注一些大厂招聘时，发现一个比较明显的变化：
AI相关能力开始进入普通软件工程岗位。

这种变化体现在几个方面：

• 面试中开始涉及大模型基础（如 Transformer 等）
• 会问到 RAG、Agent 等 AI 应用架构
• 一些岗位要求熟悉 AI coding 工具
• 岗位名称也开始发生变化，例如

AI Agent 前端开发、前端工程师 – 研发智能化、AI应用工程师

更有意思的是，这些岗位往往并不在 AI 研究团队，而是出现在业务研发团队或工程团队中。

从面试内容来看，这些问题大致可以分为三个层次：

基础层

理解大模型基本原理，例如：

• Transformer
• Token / Attention
• Embedding

这一层更像是对新基础设施的理解。

应用层

如何在系统中使用 AI，例如：

• RAG
• Prompt
• Agent
• LLM应用架构

这一层开始进入 AI 工程实践。

系统层

AI开始参与软件系统本身，例如：

• AI coding workflow
• Agent系统
• AI参与研发流程

这一层已经接近 AI-native software engineering。

这些变化可能意味着一个更深的趋势：

AI 不再只是一个独立领域，而正在逐渐成为软件工程的一部分。

当 AI 开始参与代码生成、任务执行甚至研发流程时，开发者的能力结构也在随之扩展。

某种意义上，软件工程岗位正在逐步走向 AI-native。

近期，多种 AI 工具开始引入长期记忆能力，AI 的交互模式正在从“无状态对话”逐渐走向“持续状态协作”。

例如：

• Anthropic 在 Claude 中加入自动记忆功能，使系统能够在长期任务中自动记录用户偏好与关键上下文。《How Claude remembers your project》
• Visual Studio Code 在 1.110 版本中引入 Session Memory，使 AI Agent 能够在多轮交互中持续保存计划与执行指引。《February 2026 (version 1.110)》
• 在 Agent 框架领域，诸如 Mem0 等记忆系统也逐渐成为基础组件，用于实现跨会话、跨 Agent 的长期知识管理。《别再硬扛原生记忆了！OpenClaw内置Mem0，让Agent更省token、更智能》

这些变化背后的共同趋势是：

随着 AI 开始承担越来越多的长期任务与复杂协作，系统需要具备持续记忆能力，以避免每次交互都从零开始。

在这种情况下，AI 工具的交互模式也正在发生变化——
从一次性的“无状态交互”，逐渐演变为具备持续上下文的“持续状态系统”。

长期记忆的引入，也为 AI 作为长期工作助手和复杂任务执行者提供了重要基础能力。

近期出现的一组迹象显示，AI 编程正在从“工具辅助”阶段，逐步迈向由 Agent 主导的连续软件工程执行。

• Anthropic 在《2026 Agentic Coding Trends Report》中提出，AI 编程正在从辅助编码阶段演进为由 Agent 主导的软件工程流程。
• 与此同时，智谱在《GLM-5: from Vibe Coding to Agentic Engineering》中也提出类似判断，认为 AI 编程正在从“Vibe Coding”阶段迈向“Agentic Engineering”。
• 在实际工程实践中，Cloudflare 在博文《How we rebuilt Next.js with AI in one week》中介绍，一名工程师借助 AI 模型仅用一周时间，基于 Vite 重构 Next.js 并实现实验性框架 vinext。这一案例表明，在完备的开发环境与工具链条件下，AI Agent 已经能够参与大型代码重构，从框架级别到部署流程完成较为完整的软件工程执行。

这些迹象共同指向一个变化：

AI 不再只是提升单点编码效率，而是开始逐步参与软件研发中的连续执行过程，推动研发从局部自动化走向端到端自动化。