[]
关于如何建设更高效的Agent系统，行业依然处在探索中，我们整理了一些得到实证的最佳实践，汇总如下，供参考。
在第三部分中，我们已经讨论了AI Workflow的架构设计与实现。对于AI Workflow而言，核心是把成熟、稳定、可验证的解题路径预先编排成确定性的处理流程，再让AI在其中承担认知型节点的处理工作。而到了Agent这一侧，问题就不再是“如何把AI嵌入一个既定流程”，而是“当路径不能被预先穷举时，如何让AI在明确边界之内围绕目标持续行动”。
也正因为如此，Agent的架构设计重点与AI Workflow有明显不同。工作流强调的是流程编排、上下文注入与工程治理；Agent则更强调执行层、技能体系、工具体系、上下文组织方式，以及如何让AI真正用对企业已有的软件能力。对于企业架构师来说，构建Agent系统最容易走偏的一点，是把注意力全部放在“如何从零造一个自己的Agent运行时”上，仿佛只有自己实现了一整套执行器，才算真正掌握了智能体。
但从当前行业实践来看，这条路通常并不是最优解。企业在Agent建设中真正应该投入精力的，不是重复发明一个通用执行层，而是基于已经成熟的通用型Agent执行层去构建自己的业务能力层、技能层与治理层。换句话说，企业真正的竞争力，不在于是否“自己实现了一套Agent外壳”，而在于是否能够让通用执行层稳定地理解企业的业务语义、正确地调用企业的软件系统、并始终运行在可控的安全边界之内。
在Agent架构中，执行层是承载智能体实际运行的基础环境。它负责把大语言模型、上下文、工具调用、任务状态和执行循环组织成一个可以持续推进的系统。简单来说，模型负责思考，执行层负责把这种思考变成可运行的过程。
Agent执行层：完整的执行层通常至少需要承担以下几类职责：维护会话与状态，驱动任务循环，装载Skills，注册和调用工具，管理消息输入输出，执行脚本或代码，记录日志，并处理超时、异常和中断。没有这一层，模型即使具备很强的推理能力，也很难稳定地围绕一个目标持续行动。
skills：解决的则不是“怎么运行”，而是“怎么工作”。它定义了AI在某一类任务中应当采用什么样的工作方式，包括如何拆解任务、如何使用上下文、如何选择工具、如何组织输出，以及在异常情况下优先采取什么策略。也就是说，执行层提供运行机制，skills提供工作方法。
工具：解决的则是“怎么行动”。它们把知识检索、系统查询、数据处理、消息推送、代码执行以及业务软件中的各种确定能力暴露给Agent，使其可以把推理结果落实为实际动作。也就是说，skills定义方法，工具提供抓手，执行层负责把两者组织起来持续运行。
因此，这三者并不是并列堆砌的三个组件，而是一种清晰分工。执行层负责“让系统跑起来”，Skills负责“让AI知道该怎么做”，工具负责“让AI真的做成事”。如果没有执行层，Agent无法持续运行；如果没有skills，Agent缺少稳定工作方式；如果没有工具，Agent就只能停留在思考层面。把这三者关系先理顺，后面的本体层、安全上下文与业务软件接入才有明确位置。
图：一个典型的企业级Agent的基础架构
很多团队在设计Agent架构时，容易一开始就陷入实现细节，例如应该先接多少工具、Skills应该如何拆分、执行器是否需要自己实现。但如果不先把三者的职责边界讲清楚，后面的设计很容易重复甚至混乱。最常见的情况，是把skills写成工具说明，把工具暴露成原始接口集合，最后再让执行层承担本不属于它的业务理解工作。这样一来，系统虽然也能运行，但结构会非常脆弱。
因此，在企业级Agent架构中，第一步不是急于扩展能力，而是先理顺三者分工。只有先回答清楚“谁负责运行、谁负责方法、谁负责行动”，后续关于通用执行层选型、skills治理、工具治理、本体层建设和安全上下文设计，才会有稳定的架构基础。
明确了执行层、Skills与工具的关系之后，下一个问题就是执行层的选型。这里所说的通用型执行层，并不是指某一家厂商的具体产品，而是指一类已经把任务循环、状态维护、工具注册、消息编排、脚本执行和异常处理等通用能力封装好的运行环境。例如LangSmith、Pi mono等框架提供的执行层，或OpenClaw等可扩展的产品，都可以归入这一类。
它们解决的问题并不是企业专属问题，而是所有Agent系统都会遇到的共性问题。也正因为如此，这一层的能力天然适合被平台化和通用化。对企业而言，执行层首先应当被看成基础设施，而不是差异化竞争点。
对多数企业来说，更推荐的做法是直接采用通用型执行层，而不是从零自行建设。原因也很直接。执行层本身解决的是一组高度通用的问题，例如任务循环、状态持久化、工具调用、消息输入输出、脚本执行和异常控制。这些问题当然重要，但它们并不直接构成企业在智能体建设中的核心差异。
企业真正的难点，通常不在于“有没有一个执行器”，而在于“如何让这个执行器理解业务、调用对系统、遵守权限并保持可治理”。也正因为如此，通用型执行层才具有很高的工程价值。它的意义，不是替企业完成全部工作，而是把底层通用能力先封装起来，让企业团队不必在这些已经相对标准化的问题上重复投入。这样一来，架构师和开发团队就可以把主要精力集中到更关键的层面，也就是skills管理、工具管理、ontology建设、安全上下文和业务系统接入。
当然，对于企业而言，自行建设执行层并非完全不可行，但通常不是优先级最高的投入方向。因为这会把大量资源消耗在通用能力的重复建设上，例如会话管理、任务状态持久化、工具注册机制、脚本运行环境、流式交互和异常控制等。自研等同于将大量工程资源投入到已经高度标准化的任务循环、状态管理等非差异化组件上，其边际收益远低于将同等资源投入到本体论构建等上层核心问题上。最终团队可能花了很多时间把执行器搭了起来，却还没有真正进入最困难、也最有价值的部分，也就是“让AI懂业务、会用系统、守边界”。
更重要的是，自行建设执行层并不会天然提升智能体对业务场景的适配能力。它最多只能说明团队掌握了更多底层实现细节，但企业落地真正关心的，并不是执行器是不是自己写的，而是它能否稳定地服务业务任务。因此，对于多数项目而言，更合理的做法通常不是从零实现一个新的执行层，而是基于成熟的通用型执行层向上建设企业自己的能力体系。
因此，在Agent架构设计中，推荐的重点应当明确：不是重新实现一个新的通用执行层，而是基于现有执行层去构建企业自己的业务能力体系。
这里的重点，主要体现在三个层面。第一，是如何组织Skills，让AI理解自己具备哪些工作方式。第二，是如何组织工具，让AI知道有哪些能力可被调用。第三，也是最核心的一点，是如何通过ontology、安全上下文和业务语义映射，教会AI正确地使用企业已有的软件系统。真正难的不是让Agent“会调用工具”，而是让它“调用对的工具、以对的参数、在对的上下文中去做对的事”。
在通用型Agent执行层之上，skills通常是最先被引入的一层能力。很多人初看Skills时，会把它理解为“几段写得更仔细的提示词”，但在企业级Agent架构里，Skills的意义要大得多。它并不只是告诉模型“你是谁”，而是在更大程度上规定了模型在特定任务中“应该怎样思考、怎样判断、怎样行动”。
图：Clawhub上“开箱即用”的Skills
换句话说，Skills更接近一种可被复用的工作方式描述。它可以包含任务拆解原则、上下文使用规则、输出格式要求、工具调用偏好、异常处理建议，甚至可以包含某类业务任务中被反复验证过的经验。如果把通用型执行层理解为AI的“操作系统”，那么Skills更像是面向某类任务的“工作手册”。这个比喻的另一层含义是，Skills与技术实现无关，不论是OpenClaw还是Pi-mono，可以无缝共享同一份Skill。
这使得Skills管理成为Agent系统中的一个关键主题。因为随着场景增多，企业很快就会发现，不同部门、不同任务、不同系统调用路径，往往都需要不同的思考框架和不同的行为约束。如果没有系统化的skills管理，Agent很容易在所有场景下都使用同一套宽泛提示，结果就是看起来什么都能做，实际上却很难在任何一个具体任务上保持足够稳定。
因此，Skills的价值不在于写得“像不像提示词高手”，而在于能否把业务经验稳定地沉淀下来，并在正确的场景里被加载。一个成熟的Agent系统，Skills通常应当像代码模块一样被管理：有适用范围、有版本、有依赖关系，也有逐步演进和替换的机制。
如果说Skills决定了Agent“怎么想”，那么工具管理决定的就是Agent“怎么做”。在企业级Agent中，工具可以是查询接口、搜索能力、知识库服务、数据库访问器、代码执行器、表单填写器、消息推送能力，甚至也可以是另一个Agent。
图：Agent通过A2A协议调用其他Agent
从能力扩展的角度看，工具管理的难点并不在于给AI接入更多工具。今天大多数主流执行层都已经支持工具注册、参数定义和调用编排。真正的挑战在于，当工具数量逐步增多后，如何避免AI在错误场景中调用错误工具，如何让它理解不同工具的边界，如何控制工具暴露粒度，以及如何在工具能力丰富的前提下仍然保持系统的可解释性与可治理性。
这意味着，企业中的工具管理不应只停留在“把接口接进来”这一层，而应进一步考虑以下问题：哪些能力应该直接暴露给Agent，哪些能力应该先封装成更高层的业务工具；哪些工具可以只读，哪些工具涉及副作用；哪些工具需要人工审批，哪些工具可以自动执行；同一类业务动作，是否应该被收敛为统一工具入口，而不是暴露多个细粒度接口让AI自行拼装。工具管理做得越好，Agent行为就越容易收敛；反之，如果工具层本身就是混乱的，Skills再精细，上层行为也会很难稳定。
在企业实践中，Skills与工具必须被放在一起考虑。因为Skills本身并不直接产生业务动作，它只是定义AI在某类任务中应当如何判断和选择；真正把判断变成行动的，仍然是工具。而工具如果缺少Skills的约束，又容易变成一堆对AI“理论上可用、实际上难用”的接口集合。因此，一个好的Agent架构，通常不是先问“能不能接更多工具”，而是先问“AI在这个任务里应该采用什么工作方式”，再围绕这套工作方式去暴露合适的工具。对于架构师来说，这种顺序非常重要。它决定了系统是在围绕业务任务组织能力，还是在围绕技术接口堆砌能力。
但是在讨论具体解法之前，还需要先回答一个现实问题：为什么不能像MCP等很多工具协议设想的那样，把系统能力完整暴露给模型，让模型自己去理解和选择。围绕这类机制，行业中一个常见的质疑就是当工具数量和描述信息不断增长时，模型上下文会迅速膨胀，甚至撑满整个上下文窗口，最终既增加成本，也削弱判断稳定性。尤其在企业场景中，真正需要接入的往往不是几个简单工具，而是一整套业务系统能力。此时，如果把所有工具说明、参数定义、业务术语和调用限制一次性全部放入上下文，模型理论上“看到了更多” ，实际上却更容易在噪声中失焦。
这也是为什么，企业级Agent不应追求一次性暴露全部能力，而应采用渐进式披露的思路。所谓渐进式披露，指的就是只在当前任务真正需要的时候，按步骤把相关能力、说明和上下文逐步交给AI，而不是在一开始把所有信息全部装载进同一个上下文窗口。这样做的价值非常直接：
显著控制上下文长度和Token成本
减少无关信息对当前判断的干扰
把系统能力组织成“按需学习”的过程，而不是“全量背诵”的过程。
从工程实践看，OpenClaw这类通用型执行层采用的“文本化Skills文档加CLI能力”的组合，恰好非常适合支撑这种渐进式披露。文本化的Skills文档通常使用Markdown来描述工作方式、能力边界、任务规则和使用说明，它的优势在于既足够灵活，又天然适合作为按需加载的上下文片段。CLI则进一步提供了一个清晰的能力入口，使AI不必在一开始就理解整个系统内部的所有技术细节，而是先通过少量文本化说明知道“现在应该看什么、调用什么、下一步往哪里走”，再在执行过程中逐步展开。这套方式的重要意义在于，它把“教会AI理解系统”从一次性的上下文灌输，变成了一个逐步展开的学习过程。AI不是一开始就被塞进全部系统说明，而是先读到与当前任务直接相关的那一部分规则，再通过CLI或工具入口逐步发现下一层能力。这样一来，系统不再依赖模型一次性记住全部内容，而是让模型在任务推进过程中逐步接触必要信息。这种方法既更符合大语言模型的工作方式，也更符合企业软件本身层层展开的实际结构。
图：OpenClaw渐进式读取Skills
因此，渐进式披露应当被视为企业级Agent架构中的一个关键设计原则。只有在“按需加载、逐步展开”的前提下，下面要展开介绍的本体层和业务能力说明才不会因为上下文过长而失效，Agent系统也才更有可能在复杂企业环境中保持稳定判断。
如果只看通用执行层和工具调用机制，今天的Agent似乎已经很强了。模型能识别出自己“需要查东西”，也能根据工具描述大致判断该调用哪个接口。但一旦把场景切换到企业内部，这件事情就立刻变得困难起来。原因并不复杂，企业软件并不是为了AI设计的，它有自己的业务术语、页面命名、接口习惯、权限体系和上下文逻辑。AI哪怕具备通用推理能力，也不可能天然理解每一家企业内部系统的业务含义。
也正因为如此，企业级Agent建设中最关键的问题，往往不是“AI会不会调用工具”，而是“AI能不能用对业务软件”。所谓“用对”，至少包含三层意思：知道该调用哪个能力，知道该准备什么参数，知道该如何理解返回结果。如果这三层有任何一层不稳定，整个智能体的表现都会迅速下降。
要解决这个问题，单靠工具说明通常是不够的。因为企业软件中的困难并不只是“接口叫什么”，更在于“这个接口背后对应的业务概念是什么”。同一个业务概念，在页面、数据库、接口参数和用户口语中可能会出现完全不同的名字；同一个系统动作，在业务人员和开发人员那里也可能有两套不同的表述。如果没有一种方法把这些概念与关系显式整理出来，AI即使能读懂少量接口说明，也很难真正建立起完整的业务理解。
这就是ontology在Agent架构中的意义。这里的ontology，并不是狭义学术定义上的知识图谱替代物，而是 对特定业务系统中关键概念、动作以及它们之间关系的形式化描述 。它解决的不是通用知识问题，而是特定领域的知识，即“这个业务系统里到底有什么、这些东西彼此是什么关系、哪些操作作用于哪些对象、每个结果字段又意味着什么”。
图：Ontology，从语义到执行
一旦有了ontology，AI面对业务软件时就不再只是盲目翻接口说明，而是有机会像人一样先理解“业务世界是怎么组织的”，再理解“系统能力是怎么暴露的”。这使得它不只是知道某个API叫做什么，更知道它对应的业务动作是什么，为什么应该在这一刻调用它，以及返回结果在业务上代表什么。从工程角度看，ontology层实际上是在AI与企业软件之间增加了一层语义桥梁，也让原本散落在页面、表结构、接口参数和业务术语中的隐性知识，第一次能够被AI较为系统地理解和使用。
在基于Transformer架构的LLM技术诞生和成熟之前，Ontology就已经成为了知识管理领域的共识，并且沉淀除了OWL等行业标准。早期的ontology可以理解为一张知识图谱，每个概念（Node）和概念的关系（Edge）都需要显式的声明。绘制出这张图谱需要花费较长的时间投入，这就构成了不容忽视的门槛。但随着LLM技术的发展，AI变得更擅长整理和挖掘概念间的关系，比如AI能识别出Order和订单明细之前存在主从关系，Bill和账单之间存在同义的关系。这就为降低ontology的实施门槛带来了新的机遇。比如，采用元数据驱动技术路线的低代码开发平台构建的应用，可以通过确定行的规则和程序，自动完成全部概念和部分关系的抽取，以“弱连接”的形式交给LLM，再借助AI内置的能力动态补全ontology，从而实现大幅降低ontology建设门槛的目标。
图：用文本描述的弱连接ontology
但仅仅理解业务语义还不够。即使AI知道某个能力该怎么用，也不意味着它有权去用。企业软件中的很多能力都与用户身份和权限强相关，同一个接口在不同用户上下文下返回的数据范围可能完全不同，甚至是否允许调用本身都不同。因此，企业级Agent要想真正进入生产环境，就必须解决一个比“参数对不对”更现实的问题：AI究竟是以谁的身份在行动。
这就是安全上下文的意义。所谓安全上下文，本质上是把用户身份、组织角色、会话来源、租户边界、字段权限、行权限、审批要求和调用范围等信息，一并纳入Agent执行链路之中，让AI的每一步动作都运行在一个明确、可验证的授权环境内。这样一来，智能体并不是抽象地“代表系统”行动，而是在某个具体用户或某类明确委托身份的边界内行动。
从企业治理角度看，安全上下文的价值非常关键。它不只是为了“挡住不该做的事”，也是为了让所有已做的事情都具备可审计性。换句话说，安全上下文既约束能力边界，也构成审计依据。没有这一层，Agent即使在演示时表现出色，也很难被真正纳入生产系统。
从架构层面看，ontology和安全上下文必须同时存在，才能真正让Agent“用对”业务软件。只有ontology而没有安全上下文，AI就可能会“理解能力但越权使用”；只有安全上下文而没有ontology，AI则可能“有权调用但根本不知道该怎么调用”。前者的问题是失控，后者的问题则是低效和误用。
因此，企业级Agent的关键突破点，并不是把通用型执行层做得更复杂，而是在其上增加一层业务语义理解能力和身份授权约束能力。前者告诉AI“业务世界是什么样的”，后者告诉AI“你在这个世界里现在可以做什么”。只有把这层建立起来，智能体才会从“理论上可接入企业系统”走向“实际上可稳定使用企业系统”。
当企业Agent系统逐步成型后，一个更根本的问题就会浮现出来，智能体的能力，究竟从哪里来？这个问题如果不想清楚，团队很容易把所有能力都模糊地归结为“模型自己会”，或者相反，把所有问题都变成“再接一个工具”。这两种理解都不准确。真正成熟的Agent架构，必须清楚地区分能力的来源。
从当前实践看，企业级Agent的能力大体可以分为三类。第一类是模型内置能力，也就是大语言模型在训练过程中已经具备的通用理解、推理、规划和生成能力。第二类是通过临时编写脚本或代码引入的长尾化能力，也就是AI在运行过程中借助脚本、代码执行器或通用编程环境，临时获得的数据处理和任务拼装能力。第三类是沉淀在业务软件中的确定能力，也就是企业长期建设起来的系统规则、业务流程、接口能力和权限体系。
第一类能力最容易理解。模型之所以能成为智能体的大脑，正是因为它本身已经具备相当强的语言理解、常识推理、问题拆解和自然语言生成能力。这部分能力不需要企业自己再去实现，也是智能体能快速起步的根本原因。它让Agent能够理解用户目标、阅读技能说明、结合上下文做出初步规划，并在很多场景中给出看起来颇为合理的判断。
但这部分能力也有天然边界。它擅长的是“通用问题”，不擅长的是“你这家企业内部系统里那些只属于你自己的特殊规则”。因此，LLM内置能力应当被理解为Agent的起点，而不是终点。它提供的是通用认知底座，而不是企业级确定能力本身。
第二类能力，是Agent相较于传统Workflow最有弹性的地方之一。当执行层具备代码执行器、脚本运行环境或临时工具生成能力后，AI就可以在很多长尾任务中通过“现写现用”的方式扩展自己的能力边界。例如把多个系统返回的JSON做复杂统计、把结果写成Excel、对一批文本做临时清洗、把不同来源数据做一次中间转换，甚至生成一个一次性的小工具来完成本次任务。同时，它也承担了大量需要动态逻辑和即时计算的确定性任务（如避免通过字面理解JSON格式的返回值，而是编写Python来解析），构成现代AI应用中不可或缺的核心执行手段之一。
这类能力的最大价值在于，它非常适合那些不值得长期产品化、但又确实需要解决的问题，临时脚本往往具有很高的性价比。它既不需要像正式软件那样经历完整的交付周期，也不需要每次都回到开发团队手里再造一个新工具。因此，在Agent架构中，这部分能力构成了“广覆盖”的来源。
但也正因为它是强自主性的，所以必须受到严格边界约束。脚本执行环境应当是隔离的，运行权限应当是受控的，输出结果应当是可审计的，必要时还应当设置资源限制和人工确认。也就是说，临时脚本能力可以显著增强Agent的灵活性，但它本身不能替代企业正式的软件能力。
图：国家安全部对OpenClaw等Agent执行层提出的安全建议
第三类能力，才是企业级Agent最稳定、也最值得信任的能力来源。因为这些能力并不是临时生成的，而是长期沉淀在业务软件中的确定能力。它们已经经过业务验证、权限设计、异常处理和组织协同的长期打磨，是企业数字化资产最核心的一部分。
从智能体视角看，这类能力可能表现为查询库存、创建订单、发起审批、获取报表、更新记录、写入台账、读取客户信息等一系列可操作接口。但从企业视角看，它们的真正价值在于确定性。也就是说，当AI调用这些能力时，不是在“临时猜测怎么做”，而是在调用一套已经被企业自己确认过的、可审计、可管控、可复用的业务能力。
这也是为什么，企业级Agent最终必须收束到业务软件能力之上。模型内置能力让它会思考，临时脚本能力让它能处理长尾问题，而沉淀在业务软件中的确定能力，才真正决定了它能否进入核心业务。没有这一层，智能体再灵活，也很难获得企业真正的信任。
从架构设计上看，企业Agent不应把三类能力混为一谈，而应让它们各自承担不同职责。LLM内置能力负责理解、推理、规划和表达，是智能体的认知底座；临时脚本和代码能力负责解决长尾化、探索性、一次性的数据处理与转换问题，同时也承担需要动态逻辑的确定性计算，是智能体的柔性延伸；沉淀在业务软件中的确定能力，则负责承担真正需要稳定性、准确性和审计性的核心业务动作，是智能体的可信执行基础。
也正因为如此，一个成熟的Agent系统，最终并不只是“一个很强的模型加上一堆工具”，而是一种能力分层。模型负责思考，脚本负责补位，业务软件负责兜底和落地。前两者共同提供灵活性，后者提供真正的可信度。企业如果能够把这三类能力组织清楚，就等于把智能体从“看起来很聪明”推进到了“可以放心地参与工作”。
Agent架构设计与实现的重点，从来不只是让系统具备一个会循环调用工具的执行器，而是要在通用型Agent执行层之上，构建起企业真正需要的技能体系、工具体系和治理体系。对于多数企业而言，更合理的路径并不是从零开始重新实现一个通用执行层，而是基于已经成熟的通用型执行层，把精力集中到更关键的问题上：如何管理skills，如何组织工具，如何通过ontology和安全上下文让AI真正用对业务软件。
从更深一层看，Agent的能力最终也必须回到“能力从哪里来”这一问题上。模型内置能力提供认知底座，临时脚本和代码能力提供长尾化的柔性扩展和动态逻辑执行，而沉淀在业务软件中的确定能力，则提供真正可审计、可复用、可治理的业务执行基础。只有把这三类能力分层组织清楚，企业级Agent才能既保持足够的灵活性，又始终落在企业可控的边界之内，真正成为广义智能体体系中的核心组成部分。
