一家两年前融资 2.27 亿美元、估值接近 10 亿美元的 AI 编程公司，没有宣布把整家公司卖掉。2026 年 10 月 8 日，Augment Code 同意把 Cosmos、Auggie CLI、Code Context Engine 及相关技术出售给 Harness，负责这些产品的团队也将转入后者。交易金额、没有进入交易的资产和 Augment 法人的后续安排均未披露。
这组边界比“又一家代码 Agent 被收购”更重要。Augment 给出的理由是，Harness 的一体化平台能比独立建设更有效地把这些能力交付给客户。Harness 要买的也不只是一个会写代码的助手，而是一套能从工单持续工作到待合并代码的 Agent 系统，再把它接到测试、安全、部署、运行保护和成本治理上。
Harness 买的是产品和团队，不是已确认的整家公司
Harness 的新闻标题写着“收购 Augment Code”，但正文限定为收购“选定资产”。Augment 的公告使用了更明确的交易语言：公司已经同意出售 Cosmos、Auggie CLI、Code Context Engine 及相关技术，产品团队将随之加入 Harness。独立报道 ByteFwd 也将其界定为资产交易，而非整家公司收购。
目前可以确认的清单只有三部分。Cosmos 是面向团队的“软件工厂”，可由工单、代码评审、定时任务或 webhook 触发多个专门 Agent；Auggie CLI 是开发者在终端使用的入口；Code Context Engine 为 Agent 检索与任务相关的代码结构和依赖。Cosmos 将更名为 Harness Cosmos Software Factory Agent，并已可以使用。
交易没有披露价格、现金或股权结构、团队人数、客户合同如何承接，也没有说明客户数据是否需要迁移。2024 年，Augment 曾宣布 2.27 亿美元 B 轮融资，投后估值 9.77 亿美元，累计融资 2.52 亿美元。这个融资基线说明 Augment 曾获得大额资金支持独立扩张；在缺少成交价和资产负债信息时，它不能用来判断投资回报，更不能证明 Augment 已经失败。
Augment 自己先撞上了“代码写得快，上线仍然慢”
Augment 在出售前一个月公开了自家软件工厂的演进记录。2025 年 11 月，其工程团队的新代码几乎全部借助 AI 生成；随后出现的新瓶颈却在代码评审、验证、规划、事故响应和反馈处理。Cosmos 因而从交互式编程工具扩展为持续运行的团队工作流：Agent 处理 CI 失败、评审意见和冲突，人类保留产品、架构、生产风险与最终合并决策。
这份内部案例覆盖 2025 年 11 月至 2026 年 7 月的 1.72 万个已合并拉取请求。Augment 报告称，人均规模调整后的产出从 12.3 增至 55.7，中位合并时间从 11.2 小时降至 3.1 小时，14 天内回滚率从 1.9% 降至 0.4%。这些数字来自公司自己的纵向观察，不是对照实验；同期模型、工作类型、采用率和工作流都在变化，无法把全部改善归因于 Cosmos。
真正有价值的是它记录了瓶颈怎样移动：先提高代码生成速度，只会把队列推到评审；评审加快后，还要补运行验证和事故反馈。Augment 在交易公告中承认，可靠地编排、测试、验证和部署 AI 生成的代码，正成为新的约束。这不是“代码 Agent 没用”，而是说明单独优化写代码这一段，无法决定软件何时安全到达用户。
两套上下文要连接，才能把生产问题送回代码
Augment 的 Code Context Engine 解决的是“改哪里”：它为 Agent 提供代码库、依赖和团队惯例的相关上下文。Harness 的 Software Delivery Knowledge Graph 解决的是“这次改动上线后牵动什么”：它把服务、构建、制品、环境、部署、策略、安全发现和责任团队组织成可追踪的关系。
两者连接后的目标是一条双向回路。写代码之前，Cosmos 可以读取测试要求、安全规则、部署限制和历史事故；代码产生后，Harness 的交付与安全 Agent 可以结合代码依赖判断需要哪些检查。若测试、部署验证或运行保护发现问题，系统再把失败证据和受影响对象送回 Cosmos，生成修复并重新验证。
这里必须区分“产品已经可用”和“整合已经完成”。Cosmos 本身已上线，Harness 也已有交付、安全、运行保护和成本管理产品；双方对 Code Context Engine 与 Delivery Knowledge Graph 的连接使用的是计划和目标表述。尚无公开数据证明跨系统身份能稳定对应、生产发现能自动回流，或策略与权限已经覆盖从工单到上线的全部动作。
这笔交易改变的是代码 Agent 的验收标准
对企业工程团队，这笔交易给出了一条更实际的采购基线：不要只比较 Agent 能生成多少代码，先选一个可重复工作流，衡量被接受的改动需要多久、经过哪些检查、消耗多少模型与基础设施成本，以及人工在哪些节点必须接管。代码建议的数量很容易增加，带着测试、安全和部署证据抵达合并决策的改动才更接近业务价值。
对 Harness，收购把平台边界从“代码之后”向前推到需求、实现和评审；对 Augment 团队，则是用产品独立性换取现成的企业客户、权限体系和交付基础设施。它提供了“一体化更有效”的组织选择，还没有提供“一体化已经胜出”的结果。
接下来最能检验这笔交易的，不是 Harness 能否展示一条端到端演示，而是三组可量化结果：原有 Cosmos 客户是否顺利续用，代码上下文与生产实体的映射能否减少人工排障，以及在相同质量门槛下，从工单到安全上线的周期和单次成功成本是否下降。只有这些数据出现，资产并入交付链才会从产品版图变成可验证的工程改进。
