前两天跟一个在北美做 infra 的朋友聊天，他说了句话让我印象很深：
“我们现在的问题是，AI 让写代码快了 10 倍，但部署还是和五年前一样慢。就像你买了一辆保时捷，结果每天开在村口的土路上。”
这个比喻有点糙，但道理不糙。这恰好是 Harness 这家公司这几年一直在盯着的问题——不是”怎么用 AI 写更好的代码”，而是”代码写完之后，剩下的那一大坨事情怎么办”。
先搞清楚 Harness 在做什么
简单说，Harness 做的是软件交付平台。从 CI（持续集成）到 CD（持续交付），从 feature flag 到云成本管理，从安全扫描到混沌工程——一句话，代码从程序员脑子里出来到跑在用户手机上，中间的所有环节，Harness 都想管。
但这只是表面。真正有意思的是他们最近在做的两件事：Context Graph（上下文图谱）和 Agent Loop（智能体循环）。
这两件事，单独看都挺唬人的，但串起来看，你会发现 Harness 在赌一个很大的方向。
AI Velocity Paradox：这个悖论很真实
Harness 的 CEO Jyoti Bansal 在今年 4 月的一篇博客里提了个概念叫 “AI Velocity Paradox”——AI 速度悖论。
什么意思呢？你打开 Cursor 或者 Copilot，一段 prompt 下去，函数写好了，测试生成了，PR 提了。coding 的内循环前所未有的快。但接下来呢？
CI 跑不跑得通？安全扫描过不过？谁审批？部署到哪个环境？出问题了怎么回滚？
你会发现，coding 只占了整个软件交付链条的很小一块。剩下的那些事情——管道、审批、策略、安全、监控——没有一个因为 AI 变快了。
这就是悖论：内循环加速了，外循环还在原地踏步。整体效率不但没提升，反而暴露了交付体系的瓶颈。
Context Graph：把”组织怎么干活”建模出来
大多数公司对”我们的代码怎么被交付的”这个问题，是没有统一视图的。
有人用 Jira 管需求，有人用 GitHub 管代码，有人用 Slack 沟通，有人用 PagerDuty 处理事故。每个工具里都有数据，但这些数据彼此不认识。CI 系统知道一个 build 失败了，但它不知道这个 build 跟哪个 Jira ticket 有关，也不知道是谁在 Slack 里讨论过这个问题。
Harness 的 Context Graph 要解决的就是这个。
它的核心思路很朴素：把所有工具里的事件流抓下来，洗干净，关联到统一的实体模型上，然后拼接成”任务轨迹”，最后聚合成”组织流程”。
举个例子：一个线上事故发生了。SRE 在 Slack 里说了句话，开发在 GitHub 上开了个 PR，CI 跑了一遍，安全扫描标记了一个漏洞，CD 把修复推到了 staging，审批通过后上了生产。整个过程横跨了五六个工具。Context Graph 做的事情就是把这一串事件缝成一条完整的任务轨迹，标注出每个步骤的类型、耗时、涉及的实体。
有了这些轨迹，Harness 就可以回答一些以前没人能回答的问题：
- “一个 hotfix 从发现到上线，典型的耗时要多久？”
-
“安全扫描在哪些阶段最容易被跳过？”
-
“审批是真在审查代码，还是走形式点个通过？”
更有意思的是，这些轨迹聚合成流程模式之后，就成了 AI agent 的”经验库”。agent 不再需要硬编码的 playbook，而是可以直接查询：”这种情况，历史上大家是怎么处理的？”
Agent Loop 是新的操作系统
Harness 工程团队提出了一个类比，我觉得挺妙的：Agent Loop 就是新一代的操作系统。
- 上下文窗口 = 内存（RAM）。有限的，能装的东西就那么多。
-
工具调用 = 系统调用（syscall）。agent 跟外部世界交互的方式。
-
MCP Server / orchestrator = 内核。管理资源访问，执行策略。
-
Knowledge Graph / Context Graph = 文件系统。持久化的结构化数据，agent 按需查询。
-
Schema 发现 = 虚拟内存。agent 不需要预先加载所有类型定义，用到什么查什么。
如果你接受这个类比，那设计约束就很清楚了：你不能把整个 Context Graph 塞进 agent 的上下文窗口，就像你不会把整个文件系统加载到内存里。 你得提供一套精简的查询原语，让 agent 自己去取它需要的那块切片。
Harness 团队在实践中走到了这一步：他们最开始给 MCP server 设计了 130 多个工具，每个工具对应一个具体的 API 端点。后来发现这根本没法用——agent 面对这么庞大的工具列表，光是选工具就消耗了大量 token。后来他们大刀阔斧地重构，砍到只剩 11 个通用动词（list、get、create、update、execute、describe、diagnose 等），背后靠一个资源注册表根据类型动态分发。
这是一个很有价值的教训：agent 的能力边界不在工具数量，而在后端的可查询性。工具越少越薄，后端越厚越强。
从 CAB 到 Pipeline Governance：审批这件事正在被重新定义
传统软件公司的发布流程里，有一个绕不过去的东西叫 CAB（变更顾问委员会）。一屋子人每周坐在一起，review 一堆变更请求，决定哪些能上线。
本意是好的：找人把关，别让有问题的代码跑出去。
但实际操作中，CAB 有几个致命问题：
- 表面审查。 CAB 成员通常没有深度的上下文，review 的是”证据包看起来齐不齐”，而不是”变更本身安不安全”。
-
批量风险。 变更在周期之间堆积，最后一起上线。发布越大，爆炸半径越大。
-
节奏瓶颈。 交付速度取决于会议频率，而不是团队能力。
Harness 提出的替代方案是自动发布管理：把审批逻辑从会议室搬进管道里。
安全扫描过不了？自动拦。测试覆盖率不够？自动拦。没有定义回滚流程？自动拦。
核心问题的问法变了。旧的模型问的是：”谁批了这个？”新的模型问的是：”这个变更证明了它自己能安全上线吗？”
这里有一个不容易被察觉的转变：治理不是发布的前置条件，而是管道的输出。 合规不是你在发布前要凑齐的材料，而是管道跑完自然就有的东西。
行业变革：软件工程的下一个十年
把以上这些串起来，我觉得 Harness 在赌的是三件事：
第一，软件开发的核心矛盾正在转移。 过去十年，行业在解决”怎么写代码更快”的问题——IDE、框架、云 IDE、Copilot、Cursor，这条线一直在往前推。但未来十年，核心矛盾会转移到”怎么写完之后安全地交付”。coding 加速了，delivery 必须跟上，否则加速没有意义。
第二，交付流程的可观测性会和代码一样重要。 现在做 APM 的公司很多，做代码质量的公司也很多，但做”交付流程质量”的公司还很少。你随便问一个 CTO，你们的代码测试覆盖率是多少，他可能答得出来。你问他一个 PR 从创建到上线平均要多久、瓶颈在哪，他大概率要去翻好几个系统才能给你一个大概的数。Context Graph 要填补的就是这个空白——把交付本身当作一个一等公民来观测和建模。
第三，Agent 不是替代人，是替代”查系统”这件事。 现在工程师花在”查”上的时间可能比”写”多得多——查这个环境配置对不对、查上次是谁改的这个文件、查审批走到哪一步了、查线上为什么报了这个错。这些事情，本质上都是在不同的系统之间跳转、拼凑信息。如果一个 agent 能直接回答”这个 change 历史上出过什么问题”或者”按照类似情况的常规做法，下一步应该怎么走”，那工程师就可以回到真正需要创造力的工作上去。
这也是为什么 Harness 今年推 Cursor 插件这件事值得关注。它不是做另一个 AI coding 工具——市面上够多了。它是在说：你继续用你的编辑器写代码，写完之后的整条交付管道，我来帮你串起来，你在编辑器里用自然语言就能管。 “把这个 PR 部署到 staging，安全扫描过了自动推到 production，出问题了 Slack 我”——这就是 Harness 想让你做到的事情。
但说实话，挑战也不小
Context Graph 这玩意儿好是好，但落地的坑很深。
首先是身份对齐的问题。同样一个人，在 GitHub 里叫 priya@example.com，在 Slack 里叫 priya.k@example.com，在 HR 系统里叫 Priya Kumar (Engineering)。你要是没把这三个身份证明是同一个人，后续所有的流程聚合全是歪的。这件事做起来没有技术含量，但极其吃功夫。
其次是匿名化阈值的把握。流程模式是从个人的工作轨迹聚合出来的。如果某个模式只出现在两三个人身上，那你到底是在建模”组织流程”还是在泄露个人隐私？Harness 团队引用了 Glean 的经验：一个模式至少要出现在 k 个不同用户和 n 条独立轨迹上，才算可信。这个 k 和 n 怎么定，上线之前要想清楚，而不是出了问题再补。
还有语义层的一致性问题。如果你每次接入一个新工具就给它一套临时映射，不用多久，Context Graph 里的查询就会返回矛盾的结果。工程师一旦发现数据不可信，整个系统的价值就归零了。
最后也是最容易被忽略的一点：Context Graph 是会”过期”的。团队会重组，工具会替换，流程会演变。如果一个季度不重新聚合，图谱就变成了博物馆。你以为是活的流程模型，实际上是一个过期的组织架构图。
结尾说点实在的
Harness 的工程博客里有句话我很认可：”我们不是在重新发明图数据库。我们是在把老的系统工程原则——小接口、按需分页、内容寻址存储、反馈循环——应用到一个最近两年才变得可解的问题上。”
这句话挺诚实的。Context Graph 和 Agent Loop 都不是什么天降神兵，它们背后的工程思想存在了很多年。真正不同的地方在于，AI agent 的出现让”建模组织流程并让机器推理”这件事第一次有了明确的消费场景和商业价值。
软件工程这行，每隔几年就会有人说”这次不一样”。但这次可能真有点不一样。不是因为 AI 本身有多神，而是因为 AI 让软件交付链条上那些长久被忽视的”脏活累活”第一次被摆到了台面上，并且有了被系统化解决的可能性。
至于 Harness 能不能成为这个方向的赢家——那是另一个问题了。但至少，它把问题问对了。而在我们这个行业里，问对问题比给对答案更难。
本文基于 Harness 工程博客公开资料、Harness Cursor Plugin 官方公告及 Harness 文档架构分析撰写。