Thoughtworks 发布第35期技术雷达

Thoughtworks Technology Radar 是一份每半年发布一次的 snapshot，涵盖工具、技术、平台、语言和框架。这一知识共享工具基于我们全球团队的实践经验，重点标出你可能在项目中想要探索的内容。

Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution Adopt Trial Assess Caution New Moved in/out No change No blips No blips No blips techniques platforms tools languages-and-frameworks 我们分享的每一条洞察都以一个 blip 表示。Blip 可能是最新一期 Radar 中的新条目，也可能因为我们的推荐发生了变化而移动到其他环。

Adopt。我们认为你应当认真考虑使用的 blip。 Trial。我们认为已经可以使用、但不如 Adopt 环中那些经过充分验证的东西。 Assess。值得仔细研究、但还不一定要试用的东西——除非你认为它们特别适合你。 Caution。业界应当考虑替代方案，甚至主动避开这些东西。我们有过影响工作的负面经验。

你可以按象限浏览交互版本，或下载 PDF 阅读完整版 Radar。如果想进一步了解 Radar、如何使用它或它是如何构建的，请查看 FAQ。

每一期 Technology Radar，我们都会寻找所讨论的 blip 中浮现出的模式。这些模式构成了我们各期主题的基础。

关于是否要把 harness engineering 作为单独的 blip 纳入 Radar，曾有过争论，但鉴于它是一个连接众多技术和工具的主题，我们决定在本期将其作为主题来重点呈现。

尽管这个词并不新鲜，但本期重点呈现了一个不断壮大的实践与工具生态，表明 harness engineering（我们为构建 AI agent 周边环境所做的一切，从记忆和上下文到反馈循环和护栏）正在成熟为一个更加内聚的学科。尤其是一个新兴的插件生态正在成形，Agent Plugins、agent plugin marketplace 以及 Agent Package Manager 等配套工具就是例证。

伴随这些发展，越来越清楚的一点是，harness 是一项需要持续拥有和维护的活的资产。例如，我们讨论过 harness 质量评估、构建自改进的 harness，以及利用反馈飞轮确保 agent 随时间不断改进。更广泛的挑战在于扩展 harness 以满足企业需求。未来几个月，我们可能会看到企业级 harness 作为一种产品出现，这与几年前平台和平台工程所经历的情况颇为相似。

我们正在进入 AI 模型使用的新阶段，在这个阶段，自动选择专有前沿模型不再是显而易见的选择。本期重点呈现了这一领域的重要创新，鼓励各组织更有创造性地思考该用哪些模型、如何用以及何时用。

开放权重模型在这里尤其值得关注。十二个月前，与专有前沿模型的差距还很明显，但如今对许多任务而言，这一差距已小得多。成本是主要驱动因素，但并非唯一因素：开放权重模型可以运行在你的公有云环境、neocloud 或你自己的硬件上。这种灵活性有助于满足严格的隐私要求，并减少对单一供应商的依赖。这在软件工程领域尤为明显，GLM 系列已使开放权重模型在某些编码 agent 工作负载中成为专有前沿模型的可靠替代品。自托管还可以帮助组织将源代码和 prompt 保留在自己的基础设施内。但这种转变并不局限于开放权重模型。本地编码模型正日益流行，而面向结构化数据的基础模型以及像 Jev 这样的决策模型等发展，反映出人们日益认识到前沿 LLM 并非 AI 的唯一路径。

随着可选方案日益增多，为每项任务选择合适的模型正成为工程团队的一项重要职责。模型路由正成为一项关键考量。我们提醒不要不加区分地使用前沿模型，并鼓励团队审慎选择模型，同时对替代方案保持开放。

在上一期中，编码 agent 贡献了我们大多数的 blip 和主题。这一次，许多提案聚焦于让更多 agent 投入工作，大多描述的是开发者并行运行多个 agent 会话并分别引导每一个。另一些则描述把更大块的工作交给 agent 长时间运行，例如无人值守的夜间 agentic 构建，由开发者定义任务并审查结果。与我们在前几期中介绍过的协同多 agent 方法相比，这是一种更轻量的做法。编码 agent 团队在预定义的工作流中为 agent 分配角色。编码 agent 集群则更进一步，由编排 agent 自行拆分和分配工作。在这两种做法中，开发者都下放了更多决策权。Thoughtworker 大多是在更直接的控制下运行多个会话，我们认为这是工程师一个合理的起点。

在我们讨论过的众多用于管理并行会话的工具中——包括 Claude Squad、T3 Code、Orca 和 Paseo——Herdr 引起了最多关注。大多数工具都包含一个 attention inbox，按状态组织会话，并优先处理那些等待答复或批准的会话。Omnigent 有这样一个功能，Paseo 则让开发者可以用手机查看会话。Git worktree 为每个会话提供各自的工作副本，尽管它们可能会留下一堆部分合并的分支。在一个会话内部，subagent 承担范围较窄的任务，将探索和重试排除在主上下文之外。AgentsView 让开发者回顾过去的会话，而 Hunk 则帮助他们审查 agent 生成的改动。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）