Signal #11: Agent 不只是生成代码，它的中间过程正在被产品化

Info 本周 Signal 是我持续记录 AI 与软件工程变化的栏目。 不追热点，只记录那些正在发生、且值得长期跟踪的变化。 欢迎关注和交流～

最近几个 Agent 产品的更新，给我的感觉很明显：它们越来越不像是在单纯比谁更会写代码，而是在把 Agent 工作时的“中间过程”一层层拉到前台。

上下文怎么组织，计划怎么形成，记忆怎么沉淀，执行过程怎么追踪，结果怎么评价，工具和环境权限怎么控制。

这些东西过去大多藏在 prompt、经验和人工操作里。现在，它们正在变成产品功能。

这意味着，Agent 正在从一个“代码生成入口”，变成一个需要被运行、被观察、被验证、被约束的工程系统。

对研发任务来说，这个变化尤其关键。因为真实研发任务不是一次生成，而是一段过程。

它需要理解输入，恢复上下文，判断改动范围，形成计划，选择路径，执行修改，调用工具，处理失败，重新尝试，最后还要通过测试、评审和验证。

过去，这些过程往往依赖开发者临时补充。

上下文不够，就手动把需求、代码、规范贴进去； 执行跑偏了，就提醒它重新看某个文件； 改动范围变大了，就人工叫停； 结果不可信，就再让它自查一遍。

这些操作看起来是在“用 Agent”，但实际上，人仍然承担了大量过程管理工作。

所以，当越来越多产品开始把 context usage、memory、plan、trace、review、permission、validation 这些能力显性化时，它背后的信号就不是“功能又多了几个”，而是 Agent 产品形态正在发生变化。

它不再只是围绕“生成”展开，而是开始围绕“过程”展开。

比如，Claude Managed Agents 在 5 月 6 日发布了 dreaming、outcomes、multiagent orchestration 和 webhooks。dreaming 会在会话之间回顾 agent sessions 和 memory stores，提取模式并整理记忆；outcomes 允许开发者定义成功标准，由独立 grader 评估结果，并让 Agent 根据反馈继续修正；multiagent orchestration 则支持 lead agent 拆解任务、委派给 specialist agent，并在 Console 中追踪每一步是谁做的、按什么顺序做、为什么做。(Claude《new-in-claude-managed-agents》[1])

VS Code 1.119 也把重点放在 Agent 工作流上。它强化了 agent-browser interaction、OpenTelemetry tracing、trust/security controls，并强调 Agent 可以在浏览器中验证改动、实时迭代；同时，Agent 不能自动访问浏览器页面，需要用户显式共享，这说明环境访问和权限控制也开始成为 Agent 执行过程的一部分。(Visual Studio Code updates v1.119[2])

Cursor 的变化也类似。它新增 Context Usage Breakdown，让用户看到 Agent 的上下文使用情况，用来诊断 rules、skills、MCP、subagents 带来的上下文问题；同时，它也在加强 PR Review、Build in Parallel、Split changes into PRs 这些能力，把 Agent 从“写代码”继续往评审、并行执行和变更组织推进。(Cursor changelog[3])

Gemini CLI 近期也在强化 workspace trust、.env 安全加载、shell command validation、core tools allowlist，以及 MCP resource tools 和多层 memory management。它们看起来是一些工程细节，但本质上也是在回答同一个问题：当 Agent 可以调用工具、访问环境、执行命令时，系统如何控制它能做什么、不能做什么。(Gemini CLI changelog[4])

这些变化放在一起看，指向的是同一个方向：

Agent 的中间过程，正在被产品化。

研究侧也有类似信号。

有论文把 Coding Agent 的 developer memory 设计成 MCP-native 架构，把“记忆选择”建模为可记录、有反馈、有安全门控的上下文决策过程。(arXiv《Feedback-Normalized Developer Memory for Reinforcement-Learning Coding Agents: A Safety-Gated MCP Architecture》》[5])

也有论文开始评估 Agent 生成形式化规格的能力，因为在真实软件验证里，关键问题不只是代码能不能写出来，而是规格、约束、验证条件能不能被正确表达。(arXiv《LiveFMBench: Unveiling the Power and Limits of Agentic Workflows in Specification Generation》》[6])

还有过程型 Benchmark 不再只看最终答案，而是给任务标注中间里程碑，用来衡量 Agent 到底走到了哪一步、在哪里发生推理断裂。(arXiv《DataClaw: A Process-Oriented Agent Benchmark for Exploratory Real-World Data Analysis》》[7])

这说明，Agent 时代真正值得关注的，不只是最后产物，而是产物生成之前的那一整段过程。

所谓过程能力，不是泛泛的流程管理，而是一组更具体的系统能力：

上下文管理，让 Agent 知道该看什么、不该看什么； 记忆沉淀，让 Agent 能复用过去的经验和项目规律； 计划检查，让任务拆解和执行路径提前暴露出来； 执行追踪，让每一步工具调用、文件读取、判断依据可以被看见； 评审验证，让结果不是靠感觉判断，而是进入测试、Review、浏览器、覆盖率等验证链路； 系统约束，让权限、安全、环境访问和失败恢复都有明确边界。

这些能力加在一起，才会让 Agent 从“会写代码”，走向“能承担一段真实研发任务”。

这不是说模型不重要。

模型仍然是底层能力来源。没有足够强的模型，很多任务根本无法启动。

但当模型能力继续提升后，真正决定 Agent 能不能进入真实研发流程的，开始变成另一类问题：

它能不能在复杂上下文里稳定工作？ 它的计划能不能被提前检查？ 它的执行轨迹能不能被追踪？ 它的结果能不能被验证？ 它的错误能不能被复盘和修正？ 它能不能在系统约束下持续交付？

所以，这周的 Signal 是：

未来的关键，不只是模型更会写代码，而是谁能把 Agent 的执行过程管理起来。

因为只有过程可管理，结果才可能被信任。

引用链接

[1] Claude《new-in-claude-managed-agents》: https://claude.com/blog/new-in-claude-managed-agents [2] Visual Studio Code updates v1.119: https://code.visualstudio.com/updates/v1_119 [3] Cursor changelog: https://cursor.com/changelog/05-06-26 [4] Gemini CLI changelog: https://geminicli.com/docs/changelogs/#announcements-v0410---2026-05-05 [5] arXiv《Feedback-Normalized Developer Memory for Reinforcement-Learning Coding Agents: A Safety-Gated MCP Architecture》》: https://arxiv.org/html/2605.01567v1 [6] arXiv《LiveFMBench: Unveiling the Power and Limits of Agentic Workflows in Specification Generation》》: https://arxiv.org/html/2605.01394v1 [7] arXiv《DataClaw: A Process-Oriented Agent Benchmark for Exploratory Real-World Data Analysis》》: https://arxiv.org/html/2605.02503v1