使用 harnext 编码代理开发完整的企业应用程序
十个月，1,409 个合并的 PR，三次法证审计：一个分阶段的代理管道如何将一个企业代码库从 12% 提升到 92% 的代理参与开发——配有规则、门控和一个掌控每次合并的人类。...
1 分钟阅读
AI Agents
Agentic Workflows
+3
我们给22个AI代理分配了相同的代码审查任务。相同的拉取请求、相同的固定提交、相同的提示、相同的模型——唯一的变量是每个代理如何加载项目的规则。最便宜的配置结果是最彻底的配置，其原因对上下文工程有一般性的启示。
TL;DR： 上下文引擎摘要加一个直接读取机器可读策略文件击败了所有其他策略：每次审查$1.56和9.6/13个已验证的发现——比阅读文档便宜（$2.30，8.6/13），比仅摘要更好（$1.77，7.8/13）。阅读所有内容的得分最差（7.4/13）。所有22个代理都在Claude Opus 4.8上运行，22个中有21个得出了相同的结论。
什么：一个束缚、一个上下文引擎和一个拉取请求
什么是"束缚"？
每一个认真尝试让AI代理在生产存储库中工作的尝试都会增长两层治理。
散文层——约定、架构规则、测试标准。在我们的存储库中，那是CLAUDE.md和docs/**：“后端是snake_case”，“域从不导入基础设施”，“所有路由处理程序都是异步的”。人类阅读它；代理也被告知要阅读它。
机器可读层——束缚配置。我们的是一个单一的JSON文件，将存储库中的每个路径分类为风险层级，并为每个层级附加可执行的门控。CI读取它。合并策略读取它。这不是建议——这是策略：
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
（术语说明：“束缚"也命名代理运行时本身——工具、技能和MCP服务器的脚手架，代理通过它行动，如harnext ，“编码代理束缚”。在这篇文章中，束缚配置是存储库的策略文件，这样的运行时和CI都强制执行。）
代码审查者——人类或代理——无法在没有这个文件的情况下判断"这个PR是否被允许合并？"。具有review-agent检查被跳过的第3层PR是策略违反即使每个测试都是绿色的。记住这个例子；它决定了实验。
因为两个层都存在，存储库要求一个门控：没有代理在加载这个上下文之前开始工作——并通过审查者检查的确认块证明它确实这样做了。这篇文章回答的问题很简单：满足该门控的最便宜的正确方式是什么？
认识harnext和meaninggrid
meaninggrid是来自harnext
的托管上下文引擎，QualityUnit的MIT许可、提供商无关的编码代理束缚（六个工具——读、写、编辑、bash、技能、mcp、npm i -g harnext）。供应商对上下文引擎的宣传是直率的：“你的代理的大脑。” 源流入一个不断更新的索引——“网格”——并且每个查询引擎*“将其排名和修剪成令牌高效的上下文，直接接入束缚”*：连续索引、相关性排名、重复数据删除和缓存。harnext的标题数字是平均**−89%的每查询令牌**。这是供应商的声明；这个实验的一个目的是用我们自己在真实任务上的数字来衡量这种压缩实际上节省了什么——以及它的成本。
在我们的部署中，网格摄取存储库的散文文档；每次摄取都会产生一个不可变的、版本化的快照。代理通过MCP（meaninggrid.harnext.dev/mcp）查询它，使用单个context_research调用，并接收一个综合的、带引用的摘要，用snapshot_id标记，代理必须在其确认块中引用——可审计的上下文具体化。
门控产生的东西——确认块（示例；项目特定信息省略）：
Loaded via: optimized hybrid (context-engine digest + policy file only).
- context_research call #1 (conventions / layering / testing / security /
risk tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integration checklist +
flow-engine extra-care rules) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Read harness config (full) from disk for exact tier patterns,
requiredChecks, mergePolicy, evidenceConfig.
Did NOT read CLAUDE.md or docs/* (covered by the digest).
snapshot_id是真实的——审查者可以验证代理工作所依据的规则版本。
三个假设
实验的设计是为了解决三个可测试的预测，事先写下来：
H1——摘要比重新阅读更便宜。 一次摄取散文文档，为每个代理提供一个紧凑的综合摘要，而不是每个代理在每次任务中重新阅读每个文档。*如果为真：*每次审查的成本显著降低，判决相同。
H2——释义破坏策略。 摘要可以传达"第3层需要人工审查"而不失。它不能传达"requireReviewAgent": true而不失——确切的、可引用的细节，审查者需要声称违反的细节在摘要中死去。*如果为真：*仅摘要代理应该系统地错过持有字面策略文件的代理捕获的门控违反。
H3——更精益的上下文读得更深。 上下文需要支付两次——一次是美元，一次是注意力：窗口中的每个冗余文档都与被审查的代码竞争。如果为真：阅读所有内容（摘要+所有文档）不应该获胜；最精益充分的上下文应该。
我们如何测试它
22个代理在我们的生产monorepo中审查了相同的第3层拉取请求（LLM提供商集成：44个文件，+2,111行，真实风险——计费表、流引擎路由）。五个臂，仅在上下文加载步骤中不同：
| Arm | Context loading | n |
|---|---|---|
| meaninggrid | context-engine digest only (2× context_research) | 5 |
| disk | reads 7+ docs from disk — no context engine | 5 |
| hybrid | digest + reads ALL the docs | 5 |
| opt-hybrid | digest + reads ONE file: the harness config | 5 |
| cold | no convention context at all (baseline) | 2 |
基本规则：一个固定的提交、一个提示体、一个模型——Claude Opus 4.8——所有臂交错在一个并发批中。代理被禁止访问PR的评论线程，因此早期的实验轮不会泄露。每个数字都来自原始代理记录，令牌使用按API请求去重，并按列表价格计价。质量是根据PR中13个独立验证的真实缺陷进行评分的，在每个审查的正文中进行模式匹配并手动审计以排除假阳性。所有臂的判决一致性：21/22说请求更改。
所以说什么：最便宜的配置也赢得了质量
| Arm | Cost / review | Findings (of 13) | Gate findings (of 3) | Wall clock |
|---|---|---|---|---|
| meaninggrid | $1.77 | 7.8 | 0.2 | 5:34 |
| disk | $2.30 | 8.6 | 0.8 | 4:35 |
| hybrid | $1.83 | 7.4 | 0.8 | 5:40 |
| opt-hybrid ★ | $1.56 | 9.6 | 1.4 | 4:55 |
| cold | $1.64 | 8.0 | 0.5 | 4:13 |
★ = the configuration we now ship as the repo’s default skill. Wall clock includes shared contention from running 22 agents concurrently.
H1——确认
仅摘要臂以$1.77的成本审查，而阅读文档为$2.30（−23%），获胜的摘要加一个文件臂为$1.56（−32%）——判决相同。节省复合：摘要替换了一堆文档，否则会通过每个后续 API调用的上下文。
H2——确认，决定性地
跳过的review-agent检查——这个PR中的真正合并策略违反——被5个中的5个持有字面策略文件的代理捕获，并被5个中的1个仅摘要代理捕获。机制正是H2预测的：要写出该发现，代理必须将精确的CI检查名称与精确的配置字段匹配——释义不是可引用的证据，所以仅摘要代理对冲并放弃它。一个直接读取恢复它。
H3——确认
阅读所有内容的混合臂携带了任何臂中最多的上下文，得分最差（7.4/13），而最精益充分的臂得分最好（9.6/13）——并且在所有臂中最深的单一发现上得分最好，一个死代码错误，需要跟踪跨三个文件的调用路径。冗余的散文没有添加信息；它与代码竞争注意力。
一个诚实的脚注：冷基线（8.0/13，$1.64）表明13个缺陷中的大多数是强大模型在没有任何约定上下文的情况下找到的普通代码错误。冷不能做的是工作的策略部分——门控、层级、合并规则——这正是臂分开的地方。
将散文策划成摘要。原始读取策略文件。不要读任何东西两次。
完全披露
- 模型： 每个代理的每个API调用都在claude-opus-4-8（Claude Opus 4.8）上运行——从每个记录行的
model字段验证，而不是假设。结果可能在其他模型上有所不同；较小的模型可能更多依赖精心策划的上下文，而不是更少。 - 价格： 成本使用撰写时Anthropic的列表价格；实际计费可能有所不同。相对比较不受影响。
- 样本大小： 每个臂n=5（冷的n=2），一个PR，一个存储库，一个任务类型。门控效果（5/5与1/5）很清晰；其他地方的每个发现率是±1个代理。将其视为强有力的试点，而不是基准。
- 质量指标： 审查文本上的模式检测（引用除外），手动审计以排除假阳性。它计算对已验证缺陷的提及，而不是整体审查口才。
- 时间： 所有22个代理共享一台机器和一个API配额；挂钟数字包括该竞争。
- 我们自我纠正了两次： 初始令牌计数被膨胀了2–3×（记录中的每行使用重复；通过请求ID去重修复），并且早期的时间线视觉低估了墙时间（通过完整的间隔归属修复）。两个更正都烘焙到这里的每个数字中。
现在什么：偷取循环
我们发布了什么
获胜的臂现在是存储库的默认check-context-first技能：拉取上下文引擎摘要（两个调用），然后从磁盘读取恰好一个文件——束缚配置——并发出引用快照和精确门控的确认块。一个测量的弱点，一个单行策略修复，同一天重新验证。该循环——测量、修复上下文策略、重新验证——是我们鼓励你窃取的部分，无论你使用什么上下文引擎。
你可以在周一做什么
- 将你的代理上下文分为两部分： 散文（约定、架构、测试）与机器可读策略（CI门控、风险层级、合并规则）。
- 消化散文；永远不要消化策略。 通过上下文引擎提供散文——meaninggrid是我们的——并使策略文件在你的上下文门控中成为强制性的逐字读取。
- 使上下文可审计。 版本化摄取的上下文；要求代理在确认块中引用快照id，审查者可以实际检查。
- 相信之前测量——包括我们。 你自己存储库上的每个臂几个代理足以看到模式。根据已验证的发现对审查进行评分，而不是感觉。
一个开放的邀请
如果你在你自己的存储库上运行这个实验——相同的臂、你的模型、你的束缚——我们真的很想看你的数字，特别是如果它们反驳我们的。如果你的团队想要帮助设置这样的上下文门控，或想讨论meaninggrid和harnext堆栈，请联系FlowHunt团队或在harnext.dev 找到开源束缚。欢迎复制、问题和更正。
