报道：AI编码代理在PR进入流水线后丢失上下文

AI 编程 agent 在 PR 进入流水线后就丢失了上下文。本文将说明代码上下文与交付上下文如何运作。

一个 AI 编程 agent 能读懂代码仓库、追踪依赖关系、修改十几个文件，并提交一个能通过自身测试的 pull request。随后 PR 进入交付流水线，而 agent 学到的大部分内容都留在了原地。

流水线会产生 agent 从未见过的证据：构建失败、扫描发现的漏洞依赖、部署后的延迟回归、追溯到某个看似安全的变更的事故。这些证据本可以用来改进原始变更、防止下一次故障，但前提是有某种机制能把它带回工程工作流。

写代码往往不再是慢的那一环。让变更走完构建、测试、安全、部署和运行时才是，而其中每个阶段都是风险问题。贯穿 SDLC 的上下文工程，就是把这些环节连接起来的工作。

本文介绍 agent 需要哪些上下文，Code Context Engine 和 Software Delivery Knowledge Graph 如何分别提供其中的两半，以及今天已经能用的部分和 Harness 表示仍在规划中的部分。

上下文工程是指在 AI agent 执行任务时，对其所知内容进行选择、组织、检索和维护的工作。它不只是提示词的措辞。agent 可能需要架构决策、依赖关系、仓库约定、测试结果、安全发现、部署历史和运行约束。

Agent memory 与上下文工程职责不同。Memory 存储跨会话可能有用的一切。上下文工程决定当前任务中把什么放到 agent 面前。当检索到的材料过时、矛盾或无关时，再大的 memory 存储也帮不上忙。

Augment Code 在 2026 年 2 月的 Context Engine MCP 基准测试中衡量了检索质量的影响。其中最有价值的发现与模型选择有关：上下文出色的较弱模型（Sonnet 配 MCP）可以胜过上下文糟糕的较强模型（Opus 不配 MCP）。启用 MCP 的运行还需要更少的工具调用和对话轮次。

测试跑了 300 个 Elasticsearch pull request，每个配三个提示词，共 900 次尝试，按正确性、完整性、最佳实践、代码复用和未经请求的文档打分。加入 Code Context Engine 后，Claude Code 的结果提升了 80%，Cursor 提升了 71%，Cursor 配 Composer-1 提升了 30%。原帖是在 Opus 4.5 上跑的这些测试，而 Augment 的产品页现在在 Opus 4.6 下列出同样的数字。

这些是 Augment 自己在单一代码库上的结果。它们表明检索质量会影响 agent 的输出，但并不能预测在你的仓库上能获得多少提升。

代码仓库展示代码如何工作。它不展示哪些服务对业务至关重要、哪些环境会收到变更，或上一次部署做了什么。Agent 需要这两类上下文。

代码上下文来自 Code Context Engine，它是 Harness 随收购的 Augment Code 资产一并引入的。它对代码库建立索引，让 agent 能找到相关代码及其关系，而不必用 grep 翻文件。Harness 的受治理软件工厂文章将其描述为对超过 1 亿行代码进行实时索引，包括提交历史以及哪些代码仍在使用。该文章称通用文本嵌入在代码上帮助不大，因为看起来相似的代码往往并不相关，因此 Code Context Engine 使用在代码结构上训练的嵌入模型。它通过 MCP 暴露，因此任何兼容的 agent 都能使用。

交付上下文来自 Software Delivery Knowledge Graph，这是一个描述软件如何构建、测试、加固、部署和运行的带类型模型。Harness 的受治理软件工厂文章报告称，该图涵盖 CI、CD、安全、成本和运行时中的 80 多种实体类型，并称通过该图回答一个 agent 问题约消耗 12K token，而通过原始 API 则需 250K+ token。

底层估算出自 Harness 早先关于 knowledge graph 的文章。对于一个问题——哪些流水线在各服务和漏洞中失败率最高——它给出通过原始 MCP API 调用约需 250,000 至 350,000 个输入 token 和 5 次以上 LLM 调用，而通过该图约需 12,000 个 token 和 2 至 3 次调用。它将该来源标注为内部基准测试，并未描述方法，因此应把这些数字理解为针对单次查询的数量级示意，而非基准测试。

关于 Harness 如何校验该图的答案，参见验证文章，其中报告 27 个场景中验证了 22 个，覆盖率约 81%。架构文章解释了 schema、同步和声明式查询如何使这些答案可重复。

代码上下文解释变更本身。交付上下文解释其后果。

2026 年 10 月 8 日，Harness 宣布收购 Cosmos、Code Context Engine 及相关技术。Cosmos 现在是 Harness Cosmos Software Factory Agent，它自动化从想法到代码的工程工作。它加入 Harness Autonomous SDLC Platform，在该平台中，Software Delivery、Security Testing、Runtime Protection 和 Cost Management 这几个 agent 将代码带入生产及更远阶段。

工厂文章今天所描述的内容（发布于 10 月 13 日，更新于 10 月 19 日）：

将 Code Context Engine 连接到 Software Delivery Knowledge Graph 在公告中被描述为规划中的工作，因此应把这一双向连接理解为方向，而非已交付的功能。Harness 规划了三个流程：

来自评审、测试、安全检查与部署验证的发现，带着修正和重新验证变更所需的证据，流回工程工作流

实际解读：今天 agent 已经可以在一个工作流中使用这两类上下文，而两者之间更紧密的双向连接仍在构建中。

在本文中，agent harness 是围绕编程 agent 的架构，使自主工作可靠。它有三层：

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