cs.AI, cs.SE · 2608.20622 · 20 Aug 2026

Applying Anthropic Primitives at Large Enterprises: Harness Paradigm for Knowledge Work

George Juraj Salapa

Agent Architecture Coding Harness Enterprise Governance Software Engineering

💬 前沿模型让"写代码"的成本崩了，但"审阅和维护代码"的成本没有跟着崩——每个业务问题各自定制一套方案，理解一套就要从头读一遍代码库。企业目前的应对是要么买现成产品，要么手搭 graph-orchestration 框架，要么用低代码平台当编排层，三条路都是"每次定制、范围受限"。本文提出第三条路：把 coding-agent harness 本身当作企业基础设施而不是写代码的工具——一套 harness 原封不动跑在所有部署里，代码永远相同，"审阅新构建了什么"就收敛成"读一份 instructions 文件"。

🎯 问题：代码写作成本崩塌，但审阅成本没有

专家系统的规模化困境

前沿模型把"某个领域专家自己遇到的小众问题"从难以攻克的工程任务变成了"一个下午就能写出定制代码"的小事。但审阅和维护这些代码的成本并没有随之下降——每一份方案都会朝着不同方向漂移，理解任意一份都意味着要从零开始读一遍它的代码库。这在个人层面提高了生产力，却在组织层面制造了大量互不相通、难以治理的"影子系统"。

企业现有的两种应对路径，都是"每次定制、范围受限"

大型企业目前倾向于集中治理的方案：往差里说是买一个现成产品；往好里说是针对每个用例手工搭建一套 graph-orchestration 框架，或者把低代码平台当作编排层来用。论文指出这两类方案有一个共同缺陷——它们都是"custom every time and limited in scope"：每上一个新用例都要重新定制一次，覆盖范围永远有限，无法真正复用同一套可审阅的基础设施。

🔬 方法：Harness 作为企业基础设施

第三条路：把 harness 当基础设施，而非编码工具

论文的核心主张建立在三个近期发现之上：(1) 在企业实际任务上，harness 本身就足够，甚至优于更复杂的编排架构（引用 arXiv:2604.00073、arXiv:2604.13107）；(2) 在 agent benchmark 表现的方差中，harness 的选择比模型的选择解释力更强（arXiv:2605.23950）；(3) 这一发现与企业实际采纳之间的落差，根源在于治理问题而非能力问题（arXiv:2605.10223、arXiv:2605.18747）。本文提出的架构正是要补上"治理"这一环——让一套 harness 原封不动地作为所有部署的骨架，代码在每次部署间保持完全一致，于是"审阅新构建的东西"就从"读一整个代码库"收敛为"读一份 instructions 文件"。

论文所指的 harness，即市面上 Claude Code 一类"编码 agent 外壳"——负责调用工具、管理上下文、驱动模型执行任务的运行时框架，本身不包含具体业务逻辑，业务逻辑通过指令文件（如 CLAUDE.md）和外部工具接入。

论文摘要提到"Section 4 给出四个机制"，但只列了三个

经交叉核对摘要原文与 arXiv 页面，摘要声称第4节给出四种机制，但实际枚举只有三项：credential-scoped tooling、harness 外部的 authorization 逻辑、registration-as-push-side-effect。第三项机制的描述句"collapsing an audit a review of a text file"在语法上明显不完整，疑似摘要原文的笔误或漏字，而非本报告转述时引入的错误——具体第四个机制是什么、以及这句话的完整表述，需要读全文/PDF 才能确认。

1. Credential-scoped tooling — 每个后端只配一个通用的 request 工具 + 一份范围受限的凭据，取代为每个后端手写专用方法；用统一工具 + 凭据边界替代定制集成代码，降低了每接入一个系统就要新增一套专属代码的审阅负担。

2. Authorization logic outside the harness — 授权判断被移出 harness 本体，使同一份 artifact 既能作为 cron 定时任务的后台骨架运行，也能作为聊天界面的引擎运行，还能作为终端工具运行——同一套代码、不同部署面，权限逻辑不随部署形态改变而重写。

3. Registration as a side effect of pushing code — 把"注册/上线"这个动作变成"推代码"这一操作的自然副产品，从而把原本需要专门审计流程的环节，收敛为审阅一份文本文件（大概率即 harness 的 instructions 文件）。

📊 结果 / 影响

参考实现：microcc

本文架构基于作者自建的参考 harness "microcc"（对应 PyPI 包 micro-cc）实现，用以验证上述机制的可行性。摘要及 arXiv 摘要页均未给出量化评估结果或对比实验数据——具体效果、评测指标需查阅全文（21 页，3 图，PDF 尚未解析）。

arXiv提交于 2026-08-20 · 单作者 · 无机构标注 · DOI 待 DataCite 注册

💡 与全双工 / Agent 架构方向的相关性

这篇论文不涉及全双工交互或实时推理，属于 Tier 3（Software Engineering / Agent 工程实践）范畴，但其"单一 harness 作为多部署形态统一骨架"的治理思路，对思考 duplex agent 落地时的"交互层 vs 推理层"职责划分、以及多部署面（语音通道、聊天界面、后台任务）复用同一套 agent 内核的架构设计有旁证价值——尤其是"authorization logic 移出 harness 主体，使同一 artifact 支持多种运行形态"这一点，与 duplex 架构中"交互层与思考层解耦"的设计哲学有相通之处。