Anthropic Primitives在大型企业中的应用：知识工作的Harness范式

# 在大型企业中应用Anthropic基础构件：知识工作的框架范式

来源：https://arxiv.org/html/2608.20622

## 摘要

前沿模型已大幅降低了编写定制代码的成本：过去专业领域内一个过于微小而无法获得中央预算支持的特定问题，现在只需一个下午即可解决。然而，后续代码的审查、理解和维护成本并未降低。每位专家的解决方案与其他方案渐行渐远，理解一个方案就意味着从头阅读其代码库。这种成本在企业环境中真实存在，以至于此类实践通常得不到正式认可，而管理层也仍合理地希望对运行内容拥有透明视野。

因此，大型企业转而构建集中式供给和管控的方案：最坏情况下采用现成产品，最好情况是像LangChain这样的图编排框架根据用例定制接入，或是将Copilot Studio这样的低代码对话平台本身作为编排器使用。这些模式每次都需定制，且功能有限。

近几个月逐渐兴起的框架范式则与此不同。越来越多的近期研究将编码代理框架视为企业基础设施而非编程工具。这些研究汇聚于三个发现：框架在任务层面已足够好用，且在企业工作中表现优于更复杂的代理架构（arXiv:2604.00073, arXiv:2604.13107）；框架的选择对代理基准测试结果的影响大于模型选择（arXiv:2605.23950）；而将这一发现应用于企业采用的开放差距在于治理层面（arXiv:2605.10223, arXiv:2605.18747）。基于与多家企业客户的合作实践，我们提出了一种旨在弥合该差距的架构方案。

一个框架作为核心骨架无需修改运行，其底层代码在所有部署中保持一致。因此，审查构建内容简化为阅读其指令文件。目前企业将框架保留在工程师终端，而为每个新用例单独构建实际编排层——或定制接入图编排框架，或搭建低代码平台作为编排器，或将前沿模型嫁接到现有软件上作为高级自动补全工具。我们主张相反的做法：框架本身应置于该位置。第4节提出四项实现机制。

首先是**凭证作用域工具**。我们不再为工具可能执行的每个操作构建独立方法。每个后端（如SharePoint、SQL数据仓库等）仅配备一个通用请求工具和一个绑定身份的范围化凭证。网关决定您有权访问哪些后端；一旦获得访问权限，模型将自行组合所需的任何调用。这使得治理能够适应企业真实的身份与访问系统——访问权限在凭证层面控制，而非逐项操作审查。

其次，**授权逻辑永不驻留在框架内部**，因此同一框架制品可作为无人值守的定时任务骨架、面向业务的聊天界面后端执行引擎，以及终端交互工具，在单一身份与治理模型下统一运行。

第三，**每个部署在交付时自动注册**，因此审计企业的N个代理解决方案简化为审查N个版本控制的指令文件。

第四，**模型标记为高风险的调用在送达人工审查前**，将由该框架的全新生成实例进行复核——用全新上下文评估该调用，而非由生成该调用的原始上下文自评。

这四项机制均基于同一理念：工程师分叉参考仓库，编辑指令文件和配置文件后推送代码。CI/CD构建容器、注册解决方案并部署，连接到工具注册表（可调用的工具）、解决方案注册表（已部署内容及部署者）和技能库（默认在构建时植入的程序化知识，或在配置中指定为`live`时从GitHub实时获取）。另一个运行组件是触发端点，允许Copilot Studio等聊天界面按需启动相同容器。

我们在microcc（https://pypi.org/project/micro-cc/）上构建了本文所述的架构，这是贯穿全文的参考框架实现。

## 1. 引言

当今企业运行在基于四种常见模式构建的生态系统之上。某团队在LangChain或LlamaIndex等框架上构建检索增强流程；另一团队在Semantic Kernel、CrewAI或等量的定制Python代码上为不同问题接入不同图——这是自成一体的端到端流程，与前者不共享工具层或治理模型；第三团队使用Copilot Studio等低代码对话平台为业务用户创建聊天机器人，并将其作为编排器本身；第四团队基于具备网络搜索和有限文件访问代码解释器的前沿模型部署内部聊天机器人——其推理达到顶尖水平，却无法访问企业自有文档库中的文件。

这四种模式之间不共享代码库、工具注册表或治理模型。企业承接的每个新用例都需重新启动相同的集成工作。

跨四种模式呈现出若干共性：模型作为嫁接层附加于现有软件上，成为针对问题孤立环节的高级自动补全工具；工具由工程师定义——一份手工构建的方法目录，每项预设动作对应一个方法。该目录随团队预见到的每个新系统和操作线性增长；架构选择同样因界面而异——聊天机器人团队基于低代码对话平台构建，自动化团队接入图编排框架，开发者工具团队采用终端框架，各自独立运行于自己的代码库和笔记库中；治理采取许可制——团队编写代码前需向评审委员会或安全职能部门申请许可并等待审批。许多有价值的创新因此脱离雷达视野。

另一种模式是：企业直接在Copilot Studio等低代码对话平台上构建逻辑，将其作为编排器本身。治理与审计基本免费获得，采购流程已完成，业务团队无需工程支持即可交付，这确实是优势。但代价也存在：这类平台编排能力较弱，难以处理超过少量关联动作的复杂推理链，其内部决策路径是团队无法检查或修改的黑箱。第4.9节主张为这类平台限定更窄的角色：仅作为轻量级入口和身份层。

近期另一类研究将编码代理框架视为基础设施而非编程工具，并汇聚于三个发现：框架在任务层面已足够好用，在企业工作中表现优于复杂代理架构（arXiv:2604.00073, arXiv:2604.13107）；框架选择对代理基准测试结果的影响大于模型选择（arXiv:2605.23950）；将此发现应用于企业采用的开放差距在于可治理性（arXiv:2605.10223, arXiv:2605.18747）。现有研究均未提出弥合该差距的架构。弥合差距意味着让框架在企业身份系统和审计追踪下安全运行，并支持多团队并行构建的规模——这正是本文的核心贡献。

第4节将提出该架构。为模型赋予工具、循环机制、记忆和文件系统访问能力，构成了全新的软件基础单元。API优先的十年让软件可被其他软件理解，下一前沿则是让软件可被模型理解，其基本构建模块变为“盒中模型”：循环机制、记忆、文件系统、Bash。盒子间通过消息传递组合（第4.5节），工程重心转向盒子间的边界设计。

框架作为核心骨架无需修改。工程师分叉框架后编写指令文件和配置文件并推送代码。CI/CD构建容器并部署。四项轻量级服务支撑整个集群：控制任何运行容器可调用内容的工具注册表；记录已部署内容及部署者的解决方案注册表；默认在构建时植入镜像、或在配置中指定`live`时运行时实时获取的技能库；以及允许Copilot Studio或Slack等聊天界面按需启动相同容器的触发端点。第4节将详细阐述。

我们针对现有每种模式提出替代方案：企业目前按操作定制工具——为每个预设动作手工构建方法。我们则围绕凭证构建工具目录。每个后端配备一个通用请求工具和一个绑定身份的范围化令牌；模型自行组合针对该令牌的任意调用。我们称之为**凭证作用域工具**（第4.5节）。由于访问决策在凭证层面而非逐项操作时确定，治理能够适应企业真实的身份与访问系统。

治理是部署的自然产物。每个部署在交付时自动注册，因此审计企业的N个代理解决方案简化为审查N个版本控制的指令文件（第4.7、4.8、4.11节）。

## 2. 背景与相关工作

本文描述的架构基于在欧洲多家大型企业（涵盖汽车制造、快速消费品和医疗健康行业）的实践经验。文中未具名或描述具体客户/雇主合作情况；所述主张均针对架构本身，应据此评估。下述机制基于Azure云环境提出和评估：其目录组、管理组和基于角色的访问控制影响了实现方式，但未改变底层逻辑。该架构可直接移植到其他云服务商，多数机制同样适用于本地部署环境。

近期研究已开始将编码代理框架视为基础设施而非编程工具。《终端代理足以支撑企业自动化》（arXiv:2604.00073）论证了基于终端和文件系统的代理在企业任务中表现不亚于甚至优于更复杂的MCP或基于GUI的代理架构，主张简单程序接口与强大基础模型的结合可成为企业自动化骨架。第4节与此观点一致。《编码代理能否成为通用代理？》（arXiv:2604.13107）通过开源核心ERP系统测试编码代理，发现即使完全无ERP专用工具，简单任务仍能可靠完成——这排除了工具访问作为瓶颈，将其定位为任务复杂度提升时领域逻辑与代码执行衔接的问题。研究指出四类失败：惰性启发式（用粗糙捷径实现既定策略）、幻觉（代理虚构并基于不存在的系统状态行动）、约束丢失（明确规则在长推理链中未被传递）和过度自信（代理无论结果如何均报告成功）。第4.2节的工具网关解决的问题比这些更窄：代理能否安全访问系统本身。它不直接解决四类失败模式；第4.7节的部署路径（先交互式运行任务，再将成功经验提炼至指令文件）在实践中能缓解这些问题。

《代码作为代理框架》（arXiv:2605.18747）综述代码作为编码、GUI/OS自动化及企业工作流中代理系统的操作基础，指出跨多个代理的一致共享状态、关键安全操作的人工监督等开放挑战。第4.5和4.6节直接应对这两点：模型在调用间无自身连续性，其跨运行保留的是第4.5节描述的外部工程化状态；第4.6节代码演示的机制——在高风险工具调用发起时即拦截的阻塞式审批队列——正是对人工监督的回应。

《深入Claude Code：设计空间》（arXiv:2604.14228）比较Claude Code与两个独立系统OpenClaw和Hermes Agent，发现它们对相同设计问题的解答各异，根据部署上下文占据不同设计空间区域。第4节进一步推进该对比：单一框架核心在统一身份与治理模型下供应所有三种部署上下文。

《超越自主性：动态分层AgentRunner框架》（arXiv:2605.10223）主张当前代理框架过度强调自主性而忽视企业部署所需的可治理性，提出风险分级审查机制。第4.6至4.8节的权限与审批机制即该主张的具体实践。本文描述的机制更为精简：通过一组操作原语（身份作用域权限、注册闸门、阻塞式审批队列）将现有单循环框架从本地开发者工具扩展为企业级骨架。无需单独的治理协议，也无需第二类代理来执行它。

《在不披露框架的情况下停止比较LLM代理》（arXiv:2605.23950）确立了框架选择对代理基准测试结果的影响大于模型选择。本文不进行框架对比基准测试，但遵循该研究精神直接披露：全文构建于microcc（https://pypi.org/project/micro-cc/），此为参考实现。

《通过框架工程分散安全控制》（SHarD, arXiv:2607.25890）从安全而非治理角度抵达本文主张，结论一致：组织应构建和分发的单元不是按团队购买或嫁接的定制代理配置，而是集中设计一次、无修改处处运行的加固框架。但所有研究均未涉及本文主张的部署拓扑：单一框架制品作为无人值守容器调度骨架、业务聊天界面执行引擎及终端交互工具，在统一身份与治理模型下无修改运行。这正是第4节填补的空白。

## 3. 从对话到框架的演进

四个连续模式描述了企业自2022年整合前沿模型至运营的演进历程，每个模式解决前一个的局限性。

**对话模式**。类ChatGPT的顶尖模型驱动内部聊天机器人：通过对话循环确保上下文跨轮次持续。但它形象地说没有“双手”——只能在聊天窗口内、用户上传的文件中，或用户/应用代其调用的工具内行动，永远无法自主探寻；且