作者：Lei阅读 --

Agent 变强以后，工程要做什么？深读 Thoughtworks 技术雷达 Vol.34

从 118 个技术条目中提炼一套 Agent 工程控制系统：怎样管理上下文、权限、反馈、持久化和组织度量，以及团队接下来 30 天真正值得做什么。

工程实践Agent

每一期技术雷达都有很多新名词，但真正有价值的不是记住这些名字，而是看它们被摆在了什么位置，以及这些位置合起来在讲什么故事。

Thoughtworks Technology Radar Volume 34 发布于 2026 年 4 月，共收录 118 个条目。表面上看，它几乎是一份 Agent 时代的软件开发工具大全：Context engineering、Agent Skills、Claude Code、OpenAI Codex、MCP Apps、GitHub Spec Kit、Superpowers、Coding agent swarms……

但把四个象限和四个环放在一起看，我认为这一期真正的结论并不是“Agent 已经可以接管开发”，而是：

当模型能力不再是唯一瓶颈，软件工程的主战场就从“让 Agent 更能干”，转向“让 Agent 在可理解、可约束、可验证、可恢复的系统里干活”。

换句话说，Agent 工程正在变成控制系统工程。最重要的能力不再是多写一个提示词或多接一个工具，而是把上下文、权限、反馈、状态和组织结果接成闭环。

这篇文章不打算把 118 个条目逐个翻译一遍。我更想做三件事：解释这份雷达应该怎样读；提炼其中最值得迁移的一套工程模型；最后给出一份团队可以在 30 天内落地的行动清单。

先别急着抄清单：雷达的环代表“信心”，不是“热度”

Thoughtworks 将条目分为 Techniques、Platforms、Tools、Languages and Frameworks 四个象限，再放进四个环：

  • Adopt：已经有足够实践信心，适合在匹配的场景中采用。
  • Trial：值得在能够承受风险的真实项目中试用。
  • Assess：值得研究和验证，但还不应该当作默认方案。
  • Caution：存在显著风险，需要克制使用。

Volume 34 的分布很能说明问题：

环条目数占比应有动作
Adopt1714.4%纳入默认工程能力，但仍需匹配场景
Trial3025.4%找低风险项目做受控试验
Assess6252.5%学习、做小样、建立判断，不急着标准化
Caution97.6%先弄清失败模式和退出方案

一半以上的条目仍在 Assess。这个数字比任何单个产品进入哪个环都重要：Agent 生态的供给速度已经远超组织形成稳定判断的速度。

技术雷达也不是采购榜单。一个工具进入 Adopt，只代表 Thoughtworks 在自己的交付环境中积累了足够正向经验；一个条目从雷达上淡出，也不代表它失去价值，只是有限版面不再持续追踪。把 Adopt 理解成“全公司强制安装”，或把 Assess 理解成“下个季度必须上线”，都会把雷达读反。

一张图读懂这一期：Agent 是非确定性执行器

传统自动化的输入、步骤和输出大多可预先定义；Agent 则会解释意图、选择工具、生成中间步骤，还可能在同一个任务上给出不同路径。它更像一个非确定性执行器：能力很强，但不能只靠“调用成功”证明结果正确。

要让它进入真实工程环境，至少要同时控制五件事：

flowchart LR
    I["目标与规格<br/>要解决什么问题"] --> C["上下文管道<br/>此刻应该知道什么"]
    C --> A["Agent<br/>规划与执行"]
    B["权限边界<br/>身份、最小权限、沙箱"] --> A
    D[("持久状态<br/>检查点、恢复、审计")] <--> A
    A --> X["代码与外部动作"]
    X --> S["反馈传感器<br/>Schema、编译、测试、扫描"]
    S -->|失败后修正| A
    X --> O["交付结果<br/>质量、周期、稳定性"]
    O --> M["团队度量<br/>DORA、返工、评审负担"]
    M -->|调整规格与护栏| I

这五个杠杆会产生可预测的变化：

  1. 上下文更精准，首次产出质量通常会上升；上下文只是变长，噪声和指令冲突反而会增加。
  2. 权限边界更窄，事故爆炸半径会下降；权限越广，Agent 的偶发错误越容易变成真实操作事故。
  3. 反馈越确定、越靠近执行现场，Agent 越能自我纠错；只靠最后的人肉评审，成本会随生成速度一起上涨。
  4. 状态可持久化、可恢复，长任务才有资格进入生产；否则一次网络抖动就可能让数小时工作从头再来。
  5. 度量越接近交付结果，越能看清 AI 是否真的改善生产力；只数代码和 PR，会把更多产出错当成更多价值。

后面几组看似分散的雷达条目，其实都可以放回这张图。

信号一：上下文工程进入 Adopt，“把所有东西都塞进去”进入 Caution

Context engineering 被放进 Adopt，是这一期最重要的信号之一。它与提示词工程的区别，不在于提示词写得更花，而在于把模型的信息环境当成系统来设计：静态规则放在哪里，任务知识何时检索，工具何时加载，中间结果怎样压缩，过期信息怎样退出。

与它组成完整判断的还有三项：

  • Curated shared instructions for software teams：Adopt。团队共享的 Agent 指令应该像代码规范和服务模板一样被维护，而不是散落在个人提示词收藏夹里。
  • Agent Skills 与 Progressive context disclosure：Trial。先暴露一份轻量目录，等任务真正需要时再加载详细指令、脚本和资料。
  • Agent instruction bloat：Caution。不断向 AGENTS.md、CLAUDE.md 追加“必须”和“禁止”，最终会造成冲突、注意力稀释和上下文腐化。

这四个位置合起来，给出了一条很实用的原则：

主指令文件应该是路由器，不应该是百科全书。

一个可维护的上下文栈可以分成三层：

层放什么什么时候加载
团队基线安全边界、完成定义、验证要求、通用协作方式每个任务都加载
仓库上下文架构入口、常用命令、代码约定、关键限制进入仓库时加载
任务技能发布、迁移、排障、专项测试等详细流程和脚本识别到对应任务后按需加载

新增一条指令之前，不妨先问三个问题：它适用于所有任务吗？它能被确定性工具替代吗？它是否应该放进一个按需技能？如果答案分别是“不、能、是”，继续往主文件里追加文字只是在制造未来的上下文债务。

同一逻辑也解释了为什么 MCP by default 被放进 Caution。雷达并没有否定 MCP：当你需要结构化工具契约、OAuth 边界或受治理的多租户接入时，它很有价值。但如果一个带清晰 --help、稳定 JSON 输出和可预测错误码的 CLI 已经能完成任务，再加一层协议可能只会损失接口信息、增加调试面和上下文负担。

选择集成方式时，正确问题不是“能不能 MCP 化”，而是“协议带来的治理与互操作收益，是否大于抽象和维护成本”。

信号二：真正有用的 Agent 都很“贪权限”，所以零信任必须先于自治

这一期把 Zero trust architecture 放进 Adopt，把 Sandboxed execution for coding agents 放进 Trial，把 Toxic flow analysis for AI 放进 Assess，同时把 OpenClaw 这类拥有长期记忆、私有数据和外部行动能力的个人 Agent 放进 Caution。

这不是四个孤立的安全条目，而是一条完整的风险链：

  1. Agent 需要更多上下文和工具才能变得有用。
  2. 更多上下文意味着更可能接触私有数据和不可信内容。
  3. 更多工具意味着模型输出可以变成真实外部动作。
  4. 一旦三者同时出现，提示注入或普通误判都可能穿过系统边界。

因此，不能用“模型看起来挺聪明”来换取无限权限。生产级 Agent 至少需要这些工程边界：

  • 给 Agent 独立身份，不复用开发者的长期凭证。
  • 默认只读，按任务临时提升写权限，并让凭证短期有效。
  • 文件系统、网络出口和计算资源都设边界，而不只是限制工作目录。
  • 把读取不可信内容与执行外部动作拆成不同阶段，必要时拆成不同 Agent。
  • 为高影响动作保留审批、幂等键、检查点和回滚路径。
  • 记录“看到了什么、为什么决定、调用了什么”，让事故可以复盘。

这里最容易被忽略的是：沙箱不仅是安全容器，还是自治预算。你愿意给 Agent 多大沙箱，实际上就是愿意承担多大失败成本。临时微虚拟机适合高隔离、任务完成即销毁的场景；需要长任务恢复时，则要在持久环境、检查点能力和凭证暴露之间做权衡。

信号三：最值得 Trial 的不是更多 Agent，而是反馈传感器

如果只能从这一期选一个条目投入工程资源，我会优先选择 Feedback sensors for coding agents，而不是再接入一个更会写代码的模型。

原因很简单：模型升级只能提高“可能写对”的概率，反馈传感器才能把错误变成可观察、可修正的信号。

雷达建议把编译器、类型检查、lint、结构测试和测试套件直接接进 Agent 工作循环，让失败触发及时修正，而不是等到提交以后再把问题丢给人类。与它互相加强的条目包括：

  • Structured output from LLMs：Adopt。程序消费模型输出时，优先使用 Schema 约束、校验和自动重试。
  • Browser-based component testing：Trial。组件在真实浏览器里运行，比只依赖模拟 DOM 更接近生产环境。
  • Mutation testing：Trial。主动向代码注入小错误，检查测试是否真的会失败；“测试一直绿”不等于测试有判断力。
  • Axe-core：Adopt。把无障碍检查接入反馈循环，防止 AI 生成界面把可访问性继续当成收尾工作。
  • Code intelligence as agentic tooling：Assess。把 AST、符号引用、类型层次和安全重构能力直接提供给 Agent，减少靠文本搜索重建代码结构的浪费。

一个实用的反馈漏斗可以按成本从低到高排列：

输出 Schema 校验
    ↓
格式化、编译、类型检查、lint
    ↓
单元测试、结构约束、组件测试
    ↓
变异测试、安全扫描、端到端测试
    ↓
人类评审业务取舍与不可自动判定的风险

关键不是把所有检查每次都跑一遍，而是让便宜、确定的传感器尽早失败，把昂贵的人类注意力留给机器无法清晰判断的部分。随着生成速度上升，人审不能继续承担所有质量放大成本；否则 Agent 节省的编码时间，只会转移成更长的评审队列。

信号四：多 Agent 的边界不在“能否并行”，而在“能否独立验收”

Volume 34 对多 Agent 给出了非常克制的分级：小规模、角色明确的 Team of coding agents 在 Assess；几十到几百个 Agent 动态协作的 Coding agent swarms 在 Caution。

两者的区别不只是数量。小团队通常还有明确的编排者、任务边界和合并责任；蜂群则需要动态分工、持久任务账本、分层协调和冲突合并机制。并行度越高，重复劳动、上下文不一致、冲突合并和验证成本也会一起增长。

雷达提到的两个引人注目的蜂群实验——生成 C 编译器和持续一周构建浏览器——都有普通产品开发很难复制的前提：详细规格，以及能够给出清晰反馈的强测试体系。这说明大规模并行成功的基础并不是“Agent 足够多”，而是“问题足够可分解，结果足够可判定”。

因此，给团队增加第二个 Agent 之前，可以先过三道门：

  1. 子任务能否在不共享大量隐含上下文的情况下说明白？
  2. 每个输出能否由独立测试或验收标准判断，而不是靠主 Agent 猜测？
  3. 并行修改发生冲突时，是否有明确的所有权和合并策略？

有一个问题答不上来，增加 Agent 数量就可能只是在并行制造待审代码。

类似地，Ignoring durability in agent workflows 被列入 Caution，提醒我们长程 Agent 本质上也继承了分布式系统的老问题：网络会断、模型会超时、工具会失败、人类审批可能几天后才回来。生产工作流必须保存进度和工具调用，支持幂等重试、暂停、恢复与审计。一个只能从头重跑的 Demo，不会因为换成 Agent 就自动变成生产系统。

信号五：不要度量 Agent 写了多少，要度量团队少返工了多少

在所有“新潮”条目中，DORA metrics 被放在 Adopt，反而是这一期最成熟的组织建议。Thoughtworks 的判断很明确：AI 写出更多代码，并不自动等于交付更快。

如果生成速度提高，但变更前置时间没有缩短、部署没有更稳定、返工率反而上升，那么局部编码效率只是把瓶颈推到了评审、集成和生产事故上。

与 DORA 搭配看，另外三个条目构成了一组很好的度量框架：

  • Measuring collaboration quality with coding agents：Assess：看首次接受率、每个任务的往返次数、失败构建、合并后返工和评审负担。
  • Coding throughput as a measure of productivity：Caution：不要孤立使用代码行数、PR 数量、首次输出时间衡量个人或团队。
  • Codebase cognitive debt：Caution：关注实现变化速度与团队共同理解之间不断扩大的缺口。

这里的“认知债务”比普通技术债务更隐蔽。代码可能结构整齐、测试也能通过，但团队已经说不清为什么这样设计、哪些约束不能破坏、一个局部改动会影响哪里。理解能力下降后，人也更难给 Agent 正确反馈，于是错误指导产生更多难以理解的代码，形成自我加强的循环。

我更建议团队用两层指标看 AI 开发：

层级建议指标它回答的问题
Agent 协作层首次接受率、往返次数、失败构建、评审时长人和 Agent 的协作有没有变顺
团队交付层变更前置时间、部署频率、变更失败率、恢复时间、返工率协作改善有没有变成真实业务结果

这些指标应该用于团队复盘，而不是给个人排名。否则人会自然地优化可计数的产出，让 Agent 生成更多 PR，却把质量和理解成本留给别人承担。

最有意思的反潮流：保留原则，放弃旧模式

这一期雷达的第二个主题可以概括为：保留工程原则，但不要执着于旧实现模式。

回到 Adopt 和 Trial 环，会发现不少最可靠的答案其实并不新：零信任、DORA、变异测试、真实浏览器测试、无障碍检查、结构化输出。AI 改变了工作速度和交互入口，却没有废除安全边界、反馈回路、可测试性和面向结果的度量。相反，生成速度越快，这些原则越重要。

与此同时，一些实现模式确实在变化：

  • README 和脚本可能演化为可执行的 onboarding skill。
  • 一份超长静态指令可能演化为按需加载的上下文目录。
  • IDE 里的手工导航可能演化为 Agent 可调用的 LSP、AST 和 codemod 工具。
  • 图形化集成未必总是更适合 Agent；命令行因为接口清晰、可组合、易返回结构化结果而重新变得重要。
  • 团队拓扑之外，开始需要设计 Agent 的角色、通信和反馈拓扑。

好的迁移方式不是把老工程实践全部 AI 化，而是不断区分：哪些是必须保留的原则，哪些只是过去受工具限制形成的模式。

四个象限里，哪些条目值得优先关注？

如果没有时间读完 58 页，可以先沿着下面这张精选地图阅读。它不是产品排名，而是围绕“Agent 控制系统”挑出的组合：

象限AdoptTrialAssess / Caution
TechniquesContext engineering、共享团队指令、DORA、结构化输出、零信任Agent Skills、反馈传感器、渐进式上下文、沙箱、变异测试Assess 小规模 Agent 团队、代码智能和有毒数据流；Caution 指令膨胀、认知债务、吞吐量指标、忽略持久化、默认 MCP、Agent 蜂群
Platforms—Langfuse、Amazon Bedrock AgentCore、GraphitiAgent Trace、MCP Apps、Rhesis、Sprites 等仍在 Assess；本象限没有 Caution
ToolsClaude Code、Cursor、Axe-coreOpenAI Codex、Dev Containers、cargo-mutantsAgent Scan 等在 Assess；OpenClaw 在 Caution
Languages & Frameworks本期 Adopt 主要是成熟的通用框架与数据技术DeepEval、LangGraph、LiteLLM、Agent Development KitGitHub Spec Kit、Superpowers 等工作流在 Assess；本象限没有 Caution

产品所在的环只能作为候选信号，不能替代本地验证。比如雷达把 Claude Code 和 Cursor 放在 Adopt，把 OpenAI Codex 放在 Trial；这反映的是 Thoughtworks 截至 2026 年 3 月的项目经验，而不是一张永久能力榜。工具更新可能按周发生，团队更应该沉淀跨工具的规格、技能、传感器和评测资产。

一份可以执行的 30 天计划

读完雷达最容易发生的事，是收藏十个链接，然后什么也没改变。下面是一条更小、但能闭环的落地路径。

第一周：先量基线，不买工具

  • 选一个高频、低爆炸半径、结果可验证的开发任务。
  • 记录当前前置时间、返工、失败构建和评审耗时。
  • 写清完成定义：哪些测试通过、哪些文件不可改、哪些动作需要批准。
  • 盘点 Agent 当前能看到的凭证、文件和网络出口。

第二周：重构上下文，而不是堆指令

  • 把主指令压缩成所有任务都适用的基线。
  • 将专项流程拆成按需加载的技能或短文档。
  • 给架构、领域术语、常用命令建立轻量索引。
  • 删除重复、冲突、已经可以由 lint 或测试替代的文字规则。

第三周：接入反馈与隔离

  • 按“Schema → 类型与 lint → 测试 → 安全与结构检查”接入反馈漏斗。
  • 让 Agent 在提交前读取失败结果并自我修正。
  • 用 Dev Container 或其他隔离环境限制文件、网络、凭证和资源。
  • 为写操作准备检查点、幂等控制和可恢复路径。

第四周：只看结果，决定是否扩展

  • 比较首次接受率、往返次数、评审负担和返工率。
  • 再看 DORA 指标是否出现同方向改善。
  • 记录一次失败案例：哪个传感器本可以更早发现问题？
  • 只有当任务边界清晰、输出可独立验收时，才尝试第二个 Agent 或更高自治。

30 天后，团队应该得到的主要资产不是某个工具的使用次数，而是四样可复用的东西：一份最小共享指令、一组按需技能、一套确定性反馈传感器，以及一张能够反映真实交付结果的度量表。

我的最终判断

Volume 34 最“可圈可点”的地方，是它在整个行业都追逐更强 Agent 的时候，把注意力拉回了工程系统。

它一方面承认 Claude Code、Cursor 等工具已经进入日常生产交付，Agent Skills、上下文工程和多 Agent 协作正在改变开发方式；另一方面又明确警告指令膨胀、认知债务、权限饥渴、工作流不持久、盲目 MCP 化和蜂群式扩张。

这两面并不矛盾。能力越强，越需要控制；速度越快，越需要反馈；自治越高，越需要边界；产出越多，越要用结果而不是产量衡量。

所以，如果要从这一期只带走一句话，我会选：

别再把 Agent 当成一个更快的程序员；把它当成一个非确定性执行器，并为它设计完整的控制系统。

模型和工具还会快速换代，但上下文、权限、反馈、持久化和结果度量这五个问题不会消失。能把这五个环节做成闭环的团队，才真正拥有了可以跨模型复用的 AI 工程能力。

参考资料

阅读边界：Technology Radar 是 Thoughtworks 技术咨询委员会基于其项目经验形成的观点性材料。Volume 34 的讨论会发生在 2026 年 3 月；本文保留其经验判断，同时把工具环位视为时间截面，而非通用标准或永久排名。