Harness 收购 Augment Code 资产，以将编码代理与软件交付连接起来

编写代码更改正变得更容易。让该更改经过测试、审查、保障并可靠地为客户运行仍是一项更大的工作。Harness 认为，AI 软件开发的下一次突破将来自于将这两个领域连接起来。

10 月 8 日，Harness 宣布已收购了部分 Augment Code 资产，包括 Cosmos、Auggie CLI、Code Context Engine 以及相关技术。负责这些产品的团队正加入 Harness。Cosmos 将成为 Harness Cosmos Software Factory Agent，将公司的软件交付平台扩展到变更进入部署流水线之前的工程工作。

这一区别很重要：这是一项对部分资产及其团队的收购，而不是对整个 Augment Code 公司的完整收购。其意义在于将以下技术结合在一起：能够理解并修改代码库的代理，以及能够了解代码如何被测试、发布和运行的系统。

Harness 正在其平台中引入的内容

该公告将 Cosmos 定位为日益自主的软件开发生命周期（SDLC）的起点。需求、指派的工单或报告的缺陷都可以触发一个协同工作流，代理在其中计划变更、编写代码和测试，并打开拉取请求。工程师仍在关键判断点参与其中，包括批准设计和做出最终合并决定。

这不仅仅是生成初始补丁。Cosmos 代理可以在审阅者留下评论或检查失败时继续处理同一拉取请求。预构建的专家（包括 Project Builder、PR Author、Deep Reviewer 和 PR Fixer）为团队提供了可根据自身代码库和标准进行调整的工作流。

每个代理都在隔离的虚拟机中运行。模型路由、与 GitHub、Jira 和 Slack 的集成、共享内存、版本控制以及预算控制为在整个工程组织中执行该工作提供了配套基础设施。

这种组合体现了软件工厂的理念：一种将工作推向可审查结果的可重复流程。关键的单元是完整的工程工作流，包含证据和检查点，而不是代理产生的代码行数。

Cosmos 在聊天窗口之外的工作方式

Augment 的 Cosmos 产品页面提供了该运营模型的有用细节。拉取请求、警报、计划和 webhook 可以激活专门的专家。团队围绕这些触发器定义环境、集成和人工检查点，使工作能够在无需人为为每个事件发出新提示的情况下开始。

Cosmos 还支持将专家和事件驱动的工作流定义为版本化的 YAML，通过 Auggie CLI 应用更改并在 Git 中管理配置历史。这使得代理工作流本身成为团队可以通过熟悉的工程实践进行检查和修改的对象。产品页面描述了共享的组织知识和支出上限以及这些控制措施。

对于开发团队而言，这改变了协作问题。响应指派工单的代理需要明确的目标范围、合适的工具访问权限以及报告结果的地点。由检查失败触发的代理则需要失败证据和修改相关文件的权限。可重用的工作流可以对这些需求进行编码，尽管其有效性仍取决于组织对其配置的细致程度。

Code Context Engine 是本次交易的核心

从事企业软件的代理面临一个仅凭流畅的代码响应无法自行解决的问题：寻找正确的上下文。一个代码库可能包含多个服务、已废弃的实现、本地约定以及难以从单个文件推断的依赖关系。

根据 Augment 对其 Code Context Engine 的说明，该系统对代码进行语义索引并检索与任务相关的信息。它利用跨代码库和服务的关系、提交历史、代码库模式以及文档和工单等支持材料。系统不是将整个代码库放入提示，而是对相关上下文进行排序和精选。

通过示例更容易理解其实用价值。对支付端点的更改请求可能还会影响验证、下游服务、webhook 处理程序以及测试。检索这些关联可以为编码代理提供比仅凭端点文件更好的起点。这说明了该技术所解决的问题，而并非保证能够发现所有受影响的依赖。

Harness 正在收购此上下文能力以及将其付诸实践的工具。更广阔的机会在于将代码功能的知识与代码离开代码库后发生的情况的证据相连接。

将代码库连接到运行中的系统

Harness 已经在生命周期的交付端运行。其代理覆盖软件交付、安全测试、运行时保护和成本管理。此次收购为 Cosmos 所准备的工程工作进入这些下游工作流开辟了路径。

该公司的 Software Delivery Knowledge Graph 旨在连接来自 Git、CI/CD、云基础设施、安全以及运营工具的信息。Harness 将其描述为具有结构化关系、规范身份和访问过滤的语义层。一个实际案例是解决同一服务在代码库、Kubernetes 和监控系统中出现的不同名称。

该身份问题影响重大。当一个已部署服务的漏洞发现能够追溯到相关的制品和代码版本时，其价值更高。测试失败需要关联到实际审查的变更。仅收集更多日志并不能自动建立这些关联。

在其收购公告中，Harness 描述将 Code Context Engine 和 Software Delivery Knowledge Graph 连接起来是计划中的下一步。预期的反馈回路将把下游发现返回到工程工作流，以便代理能够准备修正并再次通过验证。读者应当将这种集成方向与声称已交付完整工作流的说法区分开来。

自主仍需发布决策

该提议的回路可以减少一种常见的工程开销：在工具之间重建问题并携带其上下文。如果测试暴露出回归， 有用的输出是与失败检查关联的修正，以及修正有效性的证据。没有这些证据就打开另一个 pull request，只会把瓶颈转移到别处。

人工监督仍是架构的一部分。隔离限制了执行环境，但并不等同于补丁已正确。测试、代码审查、安全检查和明确的批准边界各自承担不同的职责。即使是绿色的测试套件也可能遗漏某些需求，技术上有效的变更仍可能不适用于特定的发布。

对于评估组合平台的客户而言，关键衡量标准将是提议的变更在审查中存活的频率、所需的返工量以及发布后可靠性如何变化。节省的补丁准备时间应与验证所花费的时间相权衡。这些是评估标准，而非收购公告所展示的性能结果。

对从构思到生产全路径的押注

Harness 表示 Cosmos 已经可用，客户可以继续使用他们偏好的编码工具。这为组织提供了选择性采用软件工厂工作流的空间，而不是将收购视为必须更换整个开发环境的要求。

战略押注十分明确。随着代码生成成为常规能力，更难的问题在于在使软件可用的各个决策之间保持上下文：实现、审查、测试、部署和运营。将 Augment 的编码资产引入 Harness，使公司在这两端都拥有关键组件。

最终，这次收购的成败将取决于这些组件是否形成可靠的反馈回路。如果生产中的发现能够导致范围明确的修复，并在正确的代码上验证后按照团队政策发布，那么收益不仅仅是更快的编码，而是将工程工作转化为客户可用软件的更佳方式。