从智能体到生产系统：企业 Agent 规模化的治理、记忆、知识与安全

进入生产环境以后，企业面对的是另一组更接近分布式系统、知识工程与安全工程的问题：Agent 数量增加后如何发现、编排、监控和退出；任务跨越数小时乃至数天后如何保持状态；运行经验如何沉淀而不是随会话消失；组织知识如何在权限、时效和来源约束下被正确调用；当 Agent 获得写入、支付、变更和执行能力时，如何把自主性关进可审计、可撤销、可恢复的边界。

本文提出"企业 Agent Operating System"框架：以运行事务为核心，以控制面、运行面、上下文面、知识面和信任面为五个协同平面，把 Agent 从一个聪明的接口改造成可治理的生产系统。

一、Agent 真正的拐点：由功能转向生产主体

过去两年，Agent 的讨论经常围绕模型推理、工具调用、规划方式和多 Agent 协作展开。模型越强，Agent 的单点成功率越高；上下文越长，复杂任务越容易做完；工具越丰富，系统能触达的业务环节越多。这些进展都重要，却容易制造一种错觉：只要继续增强单个 Agent，企业规模化自然会发生。

真实情况恰好相反。Agent 越有能力，生产化问题越早暴露。一个只能回答问题的助手，错误通常停留在文本层；一个能查库、发邮件、改工单、运行脚本和提交采购的 Agent，错误会穿过系统边界，变成真实业务状态。一个 Agent 出错可以人工兜底，一百个 Agent 同时漂移、共享过期知识或持有过宽权限，就会成为新的运营与安全负债。

企业要解决的因而不是"如何再做一个更强的 Agent"，而是"如何让大量非确定性、可调用工具、可长期运行的软件主体在同一组织中可靠工作"。这不是单纯的模型工程问题，而是平台工程、知识工程、身份安全、风险治理与组织设计的交叉问题。

（一）从确定性软件到概率性执行者，系统边界发生了变化

1、传统软件治理的对象是代码，Agent 治理的对象是运行中的决策链

传统业务系统的核心控制点相对清晰：代码版本决定逻辑，API 契约决定输入输出，数据库事务决定状态变化，权限系统决定谁能做什么。Agent 则把自然语言意图、模型推断、动态检索、工具返回、历史记忆和环境状态混合在一次运行里。同一个请求可能因为模型版本、知识索引、检索结果、工具延迟或上下文压缩方式不同而走出不同路径。

因此，企业不能只记录最终回答，而要记录完整的"决策与行动证据链"：是谁或哪个 Agent 发起，使用了哪个版本，读了哪些来源，调用了哪些工具，获得了什么授权，在哪个策略门禁被允许，产生了哪些副作用，最终由谁确认。生产问题的定位单位从"某段代码"扩展为"一次运行事务"。

2、Agent 的能力增长会同时放大价值半径与风险半径

能力、自治与风险不是三条独立曲线。工具越多，Agent 的有效权限集合越大；运行越久，状态漂移和累积错误的概率越高；记忆越持久，错误信息与恶意内容的影响周期越长；多 Agent 协作越复杂，身份传递、责任归属和级联失败越难解释。

这意味着安全不能在上线前做一次检查就结束，质量也不能用静态问答集一次验收。企业需要对每一类任务定义风险等级、行动预算、人工介入点、可恢复策略和持续评估标准。自治不是"开或关"的布尔值，而是一组按身份、资源、动作、金额、环境和时间动态计算的权限。

企业级 Agent 不是一个模型加若干工具，而是五个协同平面共同约束的一次次运行事务。

（二）四个企业问题，最终汇聚为一个操作系统问题

1、数量问题：从 Agent 列表转向 Agent Fleet

当不同部门以不同框架创建 Agent，企业很快会出现"影子 Agent"：没有统一登记，不知道负责人，不知道依赖哪些模型和工具，也不知道是否仍在使用。数量管理不是把名字列到表格里，而是建立 Agent 的资产模型、生命周期、依赖拓扑、版本策略、成本归属与退出机制。它更接近管理一支持续变化的软件舰队，因此本文使用 Agent Fleet 这一概念。

2、时间问题：从会话上下文转向可治理的记忆

长时间运行并不等于把所有历史原样塞进上下文。原始日志会膨胀，冲突事实会叠加，过期偏好会误导，敏感内容会长期滞留。真正的长期能力来自分层状态：当前任务的工作记忆、过去事件的情景记忆、稳定事实的语义记忆、可复用做法的程序记忆。它们需要不同的写入规则、保留周期、访问范围和纠错方式。

3、组织问题：从文档检索转向知识供应链

组织知识不是"把文件向量化"这么简单。企业知识具有所有权、密级、地域、版本、有效期和业务语义；同一概念在不同部门可能口径不同，同一制度在不同地区可能适用范围不同。Agent 得到的不是越多越好，而是要在正确权限下，于正确时间获得可追溯、可解释、仍然有效的最小充分上下文。

4、执行问题：从工具接入转向可验证授权

MCP 等协议让工具和数据接入更标准化，A2A 等协议让 Agent 之间的发现、任务管理和协作更开放。标准化降低了连接成本，却不会自动解决信任问题。能发现一个工具不代表可以使用它，能够调用一个远程 Agent 不代表应该继承对方权限。连接协议之上必须有独立的身份、策略、审批、沙箱、审计和撤销机制。

上述四个问题彼此耦合：没有统一身份，就无法正确隔离记忆；没有运行追踪，就无法从经验中学习；没有知识来源与版本，就无法判断失败来自模型还是过期资料；没有动作级审计，就无法把一次评估结果与真实业务影响对应起来。因此，企业需要的不是四个孤立产品，而是一套统一的 Agent Operating System。

二、数量多了怎么管：把 Agent 当作一支持续运营的软件舰队

（一）第一步不是编排，而是建立可计算的 Agent 资产目录

1、每个 Agent 都必须有"身份证、产品卡和依赖清单"

企业往往在需要跨 Agent 协作时才想到注册中心，但注册中心的首要价值其实是治理。一个可投入生产的 Agent，至少应登记以下信息：唯一身份与所有者、业务目的与服务对象、风险等级、当前版本、模型与提示配置、可用工具、可访问数据域、记忆范围、部署环境、成本中心、评估基线、审批人、应急联系人和退役日期。

这些字段不能只是文档描述，而应能被策略引擎、发布流水线、观测平台和审计系统直接引用。例如，高风险 Agent 没有明确所有者就不能发布；接入新的写工具必须触发权限复审；知识源变更后要自动关联受影响的 Agent；超过复核期限的 Agent 应进入降权或隔离状态。

2、注册的对象不仅是 Agent，还包括能力、工具、知识和策略版本

生产故障经常并非来自 Agent 本身，而来自依赖变化：检索索引更新、下游 API 字段调整、工具权限收紧、模型行为变化、提示模板被替换，都会造成输出漂移。资产目录因此要支持依赖拓扑，能够回答"这个知识库变更会影响哪些 Agent""这个工具证书泄露需要吊销哪些运行身份""某个模型版本回滚会影响哪些评估基线"。

开放协议在这里很有价值。A2A 通过 Agent Card 描述能力并以任务为中心管理长时运行，MCP 则标准化模型与工具、数据源之间的连接。企业应把这些协议元数据纳入内部目录，但不能把外部声明当成内部信任结论。能力可被发现，信任必须经验证。

Agent Registry 连接所有者、版本、依赖、风险与运行数据，使"有哪些 Agent"升级为"每个 Agent 是否仍值得、可控且合规地运行"。

（二）Agent 生命周期必须从项目制改为产品制

1、上线不是终点，退役也不是失败

Agent 所依赖的知识、用户行为、模型、工具和政策都在变化。把 Agent 当作一次性交付项目，会导致上线后无人维护：知识逐渐陈旧，接口悄然失效，权限不断累积，质量下降只在投诉时被发现。更合理的做法是为每个 Agent 指定长期产品负责人，并把生命周期明确为：提出、分诊、构建、验证、发布、监控、改进与退役。

每个阶段都应有进入与退出条件。比如，发布门禁不只检查功能成功率，还要检查失败安全性、工具权限、记忆边界、来源引用、成本上限和撤销路径；退役则要同时撤销身份、令牌、工具绑定、知识订阅和定时任务，处理记忆的归档或删除，避免留下"僵尸 Agent"。

2、版本管理要覆盖模型之外的完整行为包

Agent 的可复现版本应包含模型、系统指令、工具模式、路由策略、知识索引快照、记忆策略、评估集、输出结构和安全策略。只记录模型名称远远不够。生产环境中应把这些元素组合为不可变的 Agent Release，所有运行都关联 release_id，才能在问题出现时做精确回放、灰度比较和快速回滚。

对于高风险场景，变更应采用分层发布：离线评估、影子流量、只读运行、小比例真实流量、受限写入、全面放量。每一次扩大自治范围，都必须有独立证据，而不是把"回答更好"直接推导为"可以执行更多动作"。

生命周期中的每一道门都对应可验证证据；退役包含权限、依赖、任务与记忆的完整清理。

（三）多 Agent 编排要以任务协议为中心，而不是以聊天轮次为中心

1、长任务需要显式状态机

持续数小时或数天的任务不能依赖一条不断增长的对话链。系统需要显式任务对象，至少包含目标、输入、当前状态、计划、已完成步骤、待审批项、产物、错误、补偿动作、截止时间和责任主体。状态应可暂停、恢复、转交、取消和重试；重试必须具备幂等键，避免重复付款、重复建单或重复发送。

A2A 把任务生命周期、消息与产物设为核心，是一个重要信号：企业多 Agent 系统最终会从"谁和谁聊了几轮"转向"一个业务任务由哪些主体完成、目前处于什么状态、生成了哪些可验收产物"。编排器的价值不是替 Agent 思考所有步骤，而是为非确定性执行提供确定性的外壳。

2、交接需要最小充分上下文，而不是全量复制

Agent 之间交接时，如果复制全部对话、记忆和凭证，会同时放大成本、泄露与污染风险。更好的交接包应包含任务目标、必要事实、来源引用、完成标准、当前约束、允许动作和可用预算，并用引用指针访问原始证据。接收方只获得完成该子任务所需的最小上下文与最小权限。

这也是上下文工程与安全工程的汇合点：信息最小化不仅节省 token，也减少误导与泄露；权限最小化不仅满足合规，也降低提示注入转化为真实动作的概率。

（四）可观测性必须覆盖"模型---工具---策略---业务结果"的整条链

1、日志、指标、追踪和评估是四种不同证据

生产 Agent 至少需要四类观测信号。日志用于记录离散事件与错误；指标用于观察调用量、时延、成本、错误率和资源消耗；追踪用于还原一次运行中模型调用、检索、工具执行、Agent 交接与策略判定的因果路径；评估用于判断结果是否正确、忠实、安全并真正完成业务目标。

OpenTelemetry 正在为生成式 AI 定义厂商中立的语义约定，主流平台也开始使用统一的 span 记录模型、工具和 Agent 活动。这使跨框架观测成为可能。但企业还应增加业务语义：仅知道工具调用成功并不等于任务成功，创建了工单也不代表工单内容正确，缩短了处理时长也可能以提高升级率为代价。

2、Agent SLO 要同时包含质量、风险、成本和恢复性

传统 SLO 通常聚焦可用性与延迟，Agent SLO 至少需要五个维度：任务完成率、关键事实正确率、违规动作率、单位成功任务成本、人工接管与恢复时间。对于长任务，还应跟踪卡住率、无效循环率、重试放大率和中间产物可恢复率。

一个实用原则是把评价单位从"单次回答"升级为"业务轨迹"。最终文本可能写得很好，但如果中间读取了越权数据、进行了多余写操作或产生无法撤销的副作用，这次运行仍然不合格。反过来，Agent 主动停止并请求审批，虽然没有自动完成任务，却可能是高风险场景中的正确成功。

可观测性不仅追踪 token 和延迟，还把身份、检索来源、策略判定、工具副作用、人工审批与业务结果关联起来。

（五）评估系统要从上线验收转向持续控制

1、离线评估解决可比性，在线监测解决真实漂移

离线评估集适合做版本比较、回归测试和发布门禁；在线监测则覆盖真实用户表达、环境变化、长尾工具错误和未知组合。两者需要形成闭环：在线失败经脱敏与审核后进入问题库，再转化为新的评估用例；版本改进通过离线门禁后，以影子或灰度方式上线；真实表现继续验证是否产生副作用。

评估集也要版本化，并按任务类型、风险级别、语言、地区和用户群分层。一个整体平均分很容易掩盖关键失败。例如，客服 Agent 的总体正确率很高，但在退款政策边界上持续出错；研发 Agent 的代码通过测试，却频繁申请过宽文件权限。生产治理需要看分布、严重度和最坏情况，而不是只看均值。

2、把人工反馈变成标注证据，而不是简单点赞

"有用/没用"的二元反馈难以指导改进。更有效的反馈应定位到失败类型：事实错误、来源过期、检索遗漏、工具选择错误、参数错误、策略过严、策略放行、格式不合格或业务目标不匹配。对高风险动作，人工审批的修改内容本身就是高价值数据：系统应记录审批人改了什么、为什么改、是否可形成新的规则或程序记忆。

三、运行久了怎么积累经验：记忆不是历史堆积，而是受控学习

（一）先区分四种记忆，才能谈长期运行

1、工作记忆与情景记忆解决"这次任务发生了什么"

工作记忆服务于当前运行，包括目标、计划、暂存变量、工具返回和未完成项。它强调低延迟与一致性，任务结束后多数内容可以释放。情景记忆则保存具有复盘价值的事件：在什么条件下采取了什么动作，结果如何，哪些步骤失败，谁做了纠正。它是经验学习的原材料，但不应在未经筛选时直接进入未来提示。

长时任务还需要检查点。Anthropic 关于长时间运行 Agent 的工程实践强调，由于上下文窗口与单次会话有限，需要让 Agent 在每个阶段留下结构化进度、清晰的下一步和可验证产物，使后续运行能够恢复。这个思想比"无限上下文"更重要：恢复能力来自外部化状态，而不是指望模型永远记得。

2、语义记忆与程序记忆解决"以后应该知道什么、怎么做"

语义记忆保存经过确认的稳定事实，例如用户偏好、客户约束、项目决策或领域概念。程序记忆保存可复用的做法，例如某类故障的诊断顺序、某类合同审查的检查表、某个系统变更的安全流程。语义记忆让 Agent 少重复询问，程序记忆让组织不必反复从零探索。

程序记忆的价值最高，风险也更大。如果一次偶然成功被总结成错误规律，后续运行会系统性复制错误。因此程序记忆不应由 Agent 单方面"自我升级"，而应经过足够样本、反事实检查、权限审核和评估门禁，再发布为特定范围内可用的技能或策略。

工作、情景、语义和程序记忆具有不同的用途、写入门槛、保留周期与访问范围。

（二）真正的记忆系统是一条写入、校验、合并、检索与遗忘流水线

1、写入前先回答"什么值得被记住"

如果把每段对话都变成长时记忆，系统很快会出现噪声、冲突、隐私与成本问题。记忆写入应通过资格判定：信息是否会跨会话复用，来源是否可信，是否包含敏感数据，是否已经存在，是否具有明确作用域，是否需要用户同意，何时过期，谁有权更正或删除。

一个可治理的记忆项应至少包含事实内容、来源事件、主体范围、时间戳、置信度、敏感级别、有效期、生成方式、审核状态和版本关系。记忆不是没有来源的"模型印象"，而是一条可追溯、可纠正的派生记录。

2、合并不是摘要，必须处理冲突、时效与覆盖关系

用户上个月偏好电话联系，本月明确改为邮件；项目早期决定使用方案 A，评审后改为方案 B。如果记忆系统简单追加，检索时会同时返回冲突事实。合并逻辑需要识别实体、时间与关系，判断新信息是补充、替代、否定还是只在特定条件下成立，并保留修订历史。

当前多个云平台的记忆服务都把提取、合并、检索、TTL、身份隔离和修订记录作为核心能力，这说明行业正在从"会话缓存"走向"记忆生命周期"。企业在采用托管能力时仍需自己定义业务规则：哪些主题允许自动提取，哪些必须人工确认，哪些数据不得进入生成式记忆，哪些地区必须独立存储。

3、检索要依据任务与风险，而不是只看相似度

记忆检索不应仅做向量相似。还要过滤主体身份、Agent 身份、业务域、时间有效性、敏感级别和任务类型。对于高风险任务，未经确认或低置信度记忆只能作为线索，不能作为动作依据；对于个性化场景，用户显式偏好可以优先；对于程序记忆，只有与当前工具版本和环境兼容的流程才应生效。

4、遗忘是系统能力，不是数据清理脚本

企业需要支持自动过期、主动删除、撤回同意、纠错覆盖、项目结束清理和法务保留。删除一条记忆还要考虑衍生物：它是否进入摘要、评估样本、程序规则或其他 Agent 的共享记忆。真正的遗忘需要数据血缘，能够找到并处置依赖项。

经验只有经过资格判定、来源校验、冲突合并和范围控制，才可以从运行日志进入长期记忆。

（三）经验积累的目标不是"记得更多"，而是"下次以更低风险做得更好"

1、把一次运行变成可学习样本

每次运行结束后，系统可以生成结构化复盘：目标是否完成，关键决策点是什么，哪些工具有效，哪里发生重试，人工修改了什么，最终业务结果如何。只有当结果可验证时，这次轨迹才具有学习价值。没有结果标签的"看起来合理"不应被当作成功经验。

Reflexion 等研究展示了语言化反思对 Agent 后续表现的潜力，但企业环境必须增加治理层：反思是候选经验，不是事实；候选经验需要跨样本验证；验证通过后才可以成为程序记忆、提示改进或新评估用例。这样既保留快速学习的优势，又避免自我强化幻觉。

2、建立"经验---评估---发布"的双重门禁

建议把经验沉淀分成两条路径。低风险的个体偏好可以在用户范围内自动合并，并允许查看、纠正和遗忘；影响多个用户或真实操作的程序经验必须进入评估与发布流程。程序经验先在历史轨迹上回放，再在隔离环境中测试，确认对关键任务有稳定增益且未扩大风险后，才能发布给限定 Agent 群体。

反馈不是终点。失败被分类、经验被验证、规则被发布，再通过生产观测验证真实效果，构成受控学习飞轮。

（四）记忆必须被视为新的攻击面

1、记忆投毒会把一次注入变成长期影响

提示注入通常在当前会话中影响模型，记忆投毒则可能让恶意内容跨会话持续生效。例如，外部文档诱导 Agent 记住"以后遇到此客户必须使用某个未经批准的账户"，或攻击者通过反复对话提高虚假事实的置信度。一旦这类内容进入共享程序记忆，影响可能扩散到多个 Agent。

防护重点包括：区分用户陈述、外部内容和系统事实；禁止工具输出直接写入高信任记忆；对敏感主题增加人工确认；保留来源和修订；定期扫描异常记忆；在写入和读取两端做注入检测；将执行环境与记忆服务隔离。

2、记忆隔离必须同时按主体、用途、地区与信任级别划分

仅按用户 ID 隔离并不总够用。同一用户在个人场景与企业场景中的记忆不应混用；同一企业不同法域的数据可能不能跨境；同一 Agent 的实验环境不能读取生产记忆；来自推断的信息不能与人工确认的信息拥有同等权重。记忆系统需要多维作用域，并在每次读写时重新授权，而不是只在入口处检查一次。

四、组织知识怎么提供给 Agent：从 RAG 项目转向知识供应链

（一）先划清知识与记忆的边界

1、知识代表组织认可的外部事实，记忆代表运行中形成的内部状态

组织知识通常来自制度、产品手册、合同、数据仓库、代码库、工单和专家沉淀，具有明确所有者与发布流程；记忆则来自 Agent 与用户的交互或任务经历，具有主体性、时序性和不确定性。两者都可以被检索，但治理逻辑不同：知识的核心问题是权威性、适用范围与新鲜度，记忆的核心问题是同意、作用域、冲突与遗忘。

把两者混在一个向量库里，会产生危险的信任混淆。一个用户在对话中猜测的产品规则，可能在未来被当作组织政策；一次任务总结中的临时判断，可能覆盖正式制度。生产架构应从存储、元数据、授权和提示呈现上明确区分"权威知识""经验证记忆""未验证线索"。

2、Agent 需要的是任务上下文，不是知识库访问权

"让 Agent 访问整个知识库"是一个粗粒度表述。真正安全且高效的目标，是根据当前身份、任务、地区、时间和动作风险，组合出最小充分上下文。这个上下文可以包含权威文档片段、结构化查询结果、相关实体关系、已确认记忆和当前任务状态，但每一部分都必须带有来源、权限与有效期。

因此，知识服务不应只提供 search(query)，还应提供策略过滤、语义解析、来源证明、时间旅行查询、适用范围判断和反馈接口。知识供给从检索组件升级为生产服务。

（二）企业知识供应链包含六个连续控制点

1、源头治理：没有所有者的文档不应成为高信任知识

知识质量问题往往在进入 RAG 之前就存在：重复文件、相互冲突的流程、过期版本、扫描件解析错误、没有生效日期的通知、个人草稿与正式制度混放。Agent 会把这些组织缺陷放大，因为它能以流畅语言组合冲突信息。

每个高价值知识域都应定义数据产品负责人、权威来源、更新频率、适用范围、敏感级别和废止机制。知识源变更必须产生事件，通知索引与受影响 Agent；被撤回的文档要从检索、缓存、摘要和衍生索引中同步失效。

2、权限感知摄取：索引不能成为绕过原系统 ACL 的副本

许多 RAG 安全事故不是模型越权，而是索引阶段丢失了原始权限。文档被抽取到统一向量库后，如果查询只按相似度返回，原本分散在站点、文件夹、行级或字段级的访问控制就会消失。

正确做法是将访问控制标签、主体范围、数据地域、保留策略和来源标识随内容一起进入索引，并在检索时基于调用者与 Agent 的有效身份过滤。对于实时结构化数据，应尽量在源系统执行授权查询，而不是建立无限期副本。

3、语义加工：分块必须保留文档与业务上下文

传统分块容易把一句话从标题、时间、主体和表格中剥离。Anthropic 的 Contextual Retrieval 实验说明，为每个块补充其在原文中的简短上下文，再结合语义检索、BM25 和重排序，可以显著降低检索失败。这里更重要的启示是：检索单元不是任意长度的 token 片段，而是具有业务语义的证据单元。

企业可按文档结构、条款、产品、地区、流程步骤或实体关系分块，并保留上级标题、发布日期、适用对象和关键术语。精确编码、编号、SKU 和政策条款适合词法检索；概念性问题适合向量检索；跨文档归纳则可以使用知识图谱或 GraphRAG，先构建实体与关系，再进行局部或全局检索。

4、检索编排：让问题类型决定检索策略

不是所有问题都应该走同一条 RAG 链路。事实查找可优先关键词与结构化查询，探索性问题可使用语义检索，跨部门关系分析可使用图检索，最新状态应直接查询业务系统。检索编排器需要判断问题意图、时效要求和证据门槛，决定检索源、召回规模、重排策略和是否需要多跳。

对于高风险回答，应采用"证据先行"：先形成可核验的证据集合，再基于证据生成；如果证据不足或相互冲突，系统应停止结论并提示缺口，而不是用语言流畅度掩盖不确定性。

5、生成约束：来源必须伴随结论进入用户界面和运行日志

引用不是装饰，而是治理接口。每个关键结论应能定位到原始来源、版本与片段；用户可以点击查看，审计人员可以回放，知识负责人可以接收错误反馈。来源还要参与权限检查：即使最终回答经过摘要，也不能向用户泄露其无权查看的底层信息。

对结构化行动，证据应绑定到动作。例如，Agent 根据合同条款拒绝付款，需要记录所依据的合同版本、条款位置和业务规则；不能只保存一段自然语言解释。这样才能支持后续争议处理和策略改进。

6、新鲜度闭环：知识失效要主动触发评估与降级

知识库的版本变化可能让 Agent 的旧评估失效。重要知识源更新后，应自动识别受影响的任务与 Agent，重跑相关评估集；如果验证未通过，系统可以暂时降级为只读、强制引用或人工确认。知识新鲜度因此不是一个后台同步指标，而是 Agent 发布与运行策略的一部分。

知识供给贯穿源头治理、权限摄取、混合检索、证据组装、生成约束和反馈更新，任何一处丢失元数据都会在下游放大。

（三）MCP 解决连接标准，企业还需要"上下文治理层"

1、工具、资源和提示模板都必须纳入内部信任分级

MCP 为模型访问工具与数据源提供了通用协议，但企业不能把"兼容 MCP"理解为"可信"。远程服务器是谁运营、工具描述是否真实、认证方式是否符合要求、返回内容是否可能包含注入、数据是否跨境、版本变化是否通知，仍需要企业治理。

内部可以建立 MCP Gateway：统一完成服务器登记、身份认证、工具白名单、参数校验、速率与预算限制、内容检测、网络出口控制和审计。Agent 看见的是经裁剪的能力集合，而不是直接连接任意服务器。

2、上下文窗口要像稀缺生产资源一样被预算

更长的上下文并不保证更好的决策。无关信息会分散注意力，重复内容增加成本，未经分级的混合来源会模糊可信度。上下文治理层应为每次运行分配 token 预算，并按系统规则、任务状态、权威知识、记忆与工具返回设置优先级；超过预算时优先保留约束、证据和未完成状态，而不是机械保留最近对话。

这使"上下文工程"从提示技巧变成平台能力：不同 Agent 可以复用相同的检索、裁剪、压缩、来源标注和敏感信息处理策略。

（四）知识能力的最终评价应落在业务可验证性上

1、检索指标只是中间指标

召回率、nDCG、重排准确率可以评估检索质量，但企业更关心：答案中的关键主张有多少得到有效证据支持，引用是否真的蕴含结论，使用的是否为最新且适用版本，是否发生越权聚合，知识缺口是否被正确暴露。

建议至少建立四类评估集：已知答案的事实题、需要跨来源归纳的综合题、来源冲突与过期文档题、权限边界与敏感信息题。最后一类经常被忽视，却直接决定系统能否进入真实生产。

2、把"答不上来"设计成一种合格输出

当权威来源缺失、证据冲突或权限不足时，Agent 应明确说明无法完成的原因，并给出获得信息或升级人工的路径。这种可控拒答比自信生成更有价值。组织需要在 KPI 上奖励正确停机，而不是把自动完成率设为唯一目标，否则系统会被激励去掩盖不确定性。

五、Agent 获得执行能力之后：安全边界必须围绕身份与动作建立

（一）Agent 首先是一个独立安全主体

1、每个生产 Agent 都需要唯一、可撤销、可归责的身份

使用共享 API Key 或长期服务账号运行多个 Agent，会让权限边界与审计归属变得模糊。一旦发生误操作，很难回答是哪个 Agent、代表哪个用户、在什么任务下使用了权限。生产 Agent 应拥有独立身份，绑定明确所有者和用途，并在代表用户行动时记录 on-behalf-of 关系。

身份应该贯穿编排器、工具网关与下游系统。不能只在入口认证一次，然后让内部调用默认可信。每一跳都应重新验证主体、任务、授权范围与动作；否则一个薄弱的工具适配器就可能绕过上层策略。

2、长期身份不等于长期权限

Agent 可以有稳定身份，但高权限应是短期、任务绑定且可撤销的。微软关于 Agent 最小权限的实践提出使用独立 Agent 身份、任务范围 RBAC、即时授权、动作白名单和端到端审计。这个方向适用于任何平台：读与写分离，普通查询与高影响操作分离，权限只在明确工作流和短时间窗口内激活。

（二）授权对象必须细化到"资源---动作---条件---影响"

1、工具级白名单还不够，需要动作级与参数级策略

允许 Agent 使用"工单工具"，不等于允许删除工单、批量更新或修改管理员。策略应描述可调用的具体动作、资源范围、参数约束、数据分类、调用频率和影响上限。例如，可以允许创建单个普通工单，但批量关闭需要人工审批；可以读取某项目仓库，但不能读取密钥目录；可以生成付款草案，但不能直接提交。

1.1 决策策略与执行策略必须分离

模型可以提出"应该退款"的建议，但真正执行退款应由确定性策略引擎判断金额、用户身份、订单状态、地区规则和审批要求。把策略判断交给与内容生成同一个模型，会让提示注入同时影响意图理解与权限决定。更安全的架构是：模型负责提出候选动作，策略决策点负责允许、拒绝或要求升级，工具执行点只接受已签名授权。

1.2 授权令牌应绑定任务与不可变参数

对于高风险动作，审批不能只是一个泛化的"同意继续"。审批记录应绑定 Agent、任务、动作、资源、关键参数、金额、有效期和幂等键。任何参数变化都需要重新授权，防止 Agent 在获批后替换收款人、扩大范围或重复执行。

2、用风险分级决定人机协作方式

低风险、可逆、影响范围小的动作可以自动执行；中风险动作可采用抽样复核、额度限制和事后审计；高风险、不可逆或涉及权限变更的动作必须逐次审批、双人复核或在沙箱中演练。人机协作的关键不是"人是否在环"，而是人在什么信息基础上、何时、对哪个不可变动作做决定。

如果审批界面只显示"Agent 请求调用工具"，人也无法有效判断。界面应呈现目标、证据、预期副作用、资源范围、可撤销性、历史相似案例和策略命中原因，让审批成为真正的风险控制点。

从身份、策略、审批、工具网关、沙箱到下游系统形成多层执行边界；模型的候选动作不能直接等同于授权动作。

（三）Agent 安全威胁已经从内容风险扩展到行动链风险

1、提示注入只是起点，真正危险的是注入后的能力组合

当 Agent 只能生成文本时，提示注入主要影响内容；当 Agent 能检索内部资料并调用写工具时，同样的注入可能触发数据外泄、权限提升、错误变更或跨系统动作。风险由"恶意指令 × 可用工具 × 有效权限 × 可达数据 × 缺少门禁"共同决定。

OWASP 2026 Agentic Applications Top 10 把目标劫持、工具滥用、身份与权限滥用、供应链漏洞、意外代码执行、记忆与上下文投毒、Agent 间通信风险、级联失败、人类信任利用和失控 Agent 等列为关键风险。它们的共同特征是：失败不再局限于一次模型输出，而会沿行动链与协作网络传播。

2、多 Agent 环境需要零信任交接

一个远程 Agent 声称自己已经完成验证，不代表本地 Agent 可以直接信任其结论；一个上游 Agent 传来的上下文也可能被污染。Agent 之间应相互认证，消息应有完整性保护，能力声明应经过内部注册，交接内容按数据分类过滤，关键事实保留来源，权限不能自动传递。

对于外部 Agent 返回的产物，可以采用"数据而非指令"原则：默认把它视为不可信内容，禁止其中的自然语言直接改变系统规则；需要执行的动作必须重新经过本地策略与授权。

3、记忆、知识和工具供应链都要纳入威胁建模

传统软件供应链关注包、镜像和依赖，Agent 供应链还包括模型、提示模板、工具描述、MCP 服务器、向量索引、嵌入模型、重排器、记忆提取器和评估器。任何一层被替换或污染，都可能改变行为。企业要保存版本、签名、来源和变更记录，对关键组件实施准入、扫描、隔离与回滚。

（四）四种工程机制决定事故能否被限制和恢复

1、沙箱与网络出口控制限制可达范围

代码执行、浏览器操作和文件处理应运行在隔离环境，默认无生产凭证、无任意网络访问、无宿主文件系统写入。按任务挂载最小数据与短期凭证，运行结束立即销毁。网络出口通过代理或网关白名单控制，阻断任意外传与未登记工具连接。

2、预算与速率限制阻断失控循环

Agent 可能因为推理错误、工具失败或恶意内容陷入循环。每次任务应有 token、时间、工具调用次数、金额、写操作数量和递归深度预算。接近预算时降级、暂停或请求人工，而不是无限重试。预算是安全边界，也是 FinOps 边界。

3、幂等、补偿与检查点让失败可恢复

真实业务操作必须设计幂等键，防止重试产生重复副作用；复杂工作流应为关键步骤定义补偿动作，例如撤销预订、恢复配置或关闭错误工单；长任务在每个可恢复阶段保存检查点。没有补偿能力的动作应被视为更高风险，采用更严格审批。

4、Kill Switch 必须真实测试

停用控制不能只存在于管理后台。企业需要验证能否快速禁用 Agent 身份、吊销令牌、停止正在运行的任务、阻断工具网关、冻结记忆写入并保留取证日志。测试指标不是"有开关"，而是平均撤销时间、残留会话数量和下游系统是否立即重验权限。

六、统一架构：企业 Agent Operating System 的五个平面

（一）控制面回答"谁可以以什么方式存在"

1、Agent Registry 是治理事实源

控制面维护 Agent 身份、所有者、版本、风险、依赖、策略、评估基线与生命周期状态。构建、发布、运行、观测和退役都围绕同一资产 ID 展开。它还提供能力目录，使编排器可以按任务、地域、成本和合规条件选择合适 Agent，而不是把路由硬编码在提示中。

2、发布与策略必须声明式、可回滚

Agent Release 把模型、指令、工具、知识、记忆策略和安全策略组合为版本化声明。发布流水线通过评估、红队、权限审核和成本测试生成证据；运行时按声明加载。出现问题时，平台可以回滚某个行为包，而不是临时修改多个系统。

（二）运行面回答"任务如何可靠地完成"

1、任务状态机为非确定性推理提供确定性外壳

运行面负责任务分解、Agent 选择、暂停恢复、重试幂等、检查点、补偿、人工审批和产物管理。模型可以动态规划，但状态变更必须写入外部事务存储。任何长时任务都能回答当前进度、下一步、阻塞原因和剩余预算。

2、可观测性与评估是运行时内建能力

每个模型调用、检索、策略判定、工具动作与交接都生成标准化 span，并关联任务、Agent、版本、身份和成本。在线评估器对关键轨迹进行抽样或全量检查，触发告警、降级和问题归档。观测不是上线后的外挂，而是运行协议的一部分。

（三）上下文面与知识面回答"Agent 此刻应该知道什么"

1、上下文面管理任务状态与多层记忆

上下文面负责工作记忆、检查点、情景记录、语义记忆与程序记忆的写入、合并、检索、TTL 和删除。它执行主体隔离与信任分级，并根据任务预算组装最小充分上下文。

2、知识面交付带权限、版本和来源的组织事实

知识面连接权威数据源、结构化系统和内容仓库，通过混合检索、图谱和实时查询生成证据包。知识结果不是裸文本，而是包含来源、适用范围、新鲜度、权限与置信信息的对象，供生成和策略共同使用。

（四）信任面回答"哪些动作在什么条件下可以发生"

1、身份、策略与工具网关形成统一执行边界

信任面维护 Agent 与用户身份、任务授权、动作策略、即时权限、审批令牌、沙箱、网络出口和密钥服务。所有高影响动作都经过策略决策点与执行点，模型不能绕过。

2、审计、红队与事件响应形成持续保证

信任面保存端到端证据链，运行提示注入、记忆投毒、工具滥用、权限升级、跨 Agent 欺骗和级联失败测试，并提供吊销、隔离、回放和恢复能力。NIST AI RMF 的 Govern、Map、Measure、Manage 可以作为组织治理骨架，而 Agent 特有的动作链风险需要映射到具体运行控制。

五个平面不是五个孤岛，它们通过统一的 Agent ID、Task ID、Release ID、Policy ID 和 Trace ID 连接成可治理事务。

（五）这套架构的核心数据模型是"运行契约"

1、运行契约把意图转化为可验证约束

每次高价值任务在执行前生成运行契约，至少包含：发起者、代表关系、目标、Agent 版本、允许知识域、允许工具与动作、数据范围、预算、截止时间、成功标准、审批点、禁止事项、补偿策略与证据保留要求。契约可以由用户意图与组织策略共同生成，但必须由确定性组件签发。

2、所有平面围绕同一契约协同

运行面依据契约推进状态；上下文面只读取允许范围；知识面按身份过滤证据；信任面为具体动作签发短期授权；观测系统验证是否偏离；评估系统判断是否达到成功标准。这样，Agent 的自主性不再依赖一段无法审计的系统提示，而被编码为可计算、可回放、可撤销的生产边界。

七、组织与指标：平台不是唯一答案，运营机制同样重要

（一）建立"中心平台 + 领域负责"的联邦治理

1、中央团队建设公共底座与黄金路径

中央 Agent 平台或卓越中心负责身份标准、资产目录、发布门禁、观测规范、评估框架、工具网关、记忆与知识基础设施、安全测试和事件响应。其目标不是审批每一个创意，而是让合规做法成为默认路径，让新 Agent 能复用成熟组件。

2、领域团队对价值、知识和风险负责

领域团队最了解业务目标、知识口径、失败成本和用户反馈，应拥有 Agent 产品负责人、知识负责人和风险负责人。中央团队不能替代领域判断。一个有效的责任模型是：平台团队对"控制是否可用"负责，领域团队对"控制是否正确配置、业务结果是否值得"负责，安全与合规团队对高风险边界进行独立监督。

（二）指标体系必须防止局部优化

1、价值指标与系统指标成对出现

只看自动化率，会鼓励 Agent 避免升级人工；只看成功率，会掩盖高成本重试；只看用户满意度，可能忽视越权读取。建议建立四组指标：业务价值、任务质量、运行效率和风险韧性，并对高风险场景设置硬门槛。

维度	示例指标	需要警惕的误导
业务价值	净节省时长、一次解决率、业务周期缩短	把工作转移给审核人员却仍计为自动化
任务质量	完成率、事实正确率、证据覆盖率、人工修改率	平均值掩盖关键边界案例
运行效率	单位成功任务成本、p95 时延、工具重试率	通过减少验证步骤换取低成本
风险韧性	越权动作率、正确停机率、平均撤销时间、恢复成功率	只统计已发生事故，忽略近失事件

2、用风险调整后的单位经济性决定是否扩大自治

Agent 的 ROI 不应只计算模型和算力成本，还包括知识维护、人工审批、平台运营、安全控制、事故预期损失和机会成本。可以使用"每个合格任务的全成本"作为核心经济指标：总运行与治理成本除以同时满足质量和风险门槛的任务数量。失败、越权或必须返工的任务不能计入分母。

这一指标会推动团队优化真正有价值的稳定自动化，而不是追求调用量和表面完成率。

（三）成熟度不是 Agent 数量，而是自治与控制同步增长

1、五级成熟度模型

|----------|--------------------|-----------------------|
| 级别 | 运行特征 | 关键治理能力 |
| L0 实验 | 单 Agent、人工触发、无生产写入 | 基础评估、数据隔离 |
| L1 受控助手 | 有限检索和只读工具 | 资产登记、来源引用、访问控制 |
| L2 受限执行 | 少量可逆写操作 | 独立身份、动作白名单、审批与审计 |
| L3 协同生产 | 多 Agent、长任务、跨系统流程 | 任务状态机、检查点、统一追踪、补偿 |
| L4 学习型组织 | 经验持续沉淀并跨 Agent 复用 | 记忆治理、评估驱动发布、持续红队与动态策略 |

成熟度升级的必要条件是控制能力先于或至少同步于自治能力。企业不应因为模型升级就自动把 L1 Agent 提升到 L3；跨级提升必须补齐身份、状态、知识、恢复和安全基础设施。

2、规模化的正确目标是可复制，不是无差别集中

并非所有 Agent 都要运行在同一框架，也不必强制统一模型。真正需要统一的是身份、元数据、任务协议、观测语义、策略接口、知识与记忆边界以及发布证据。底层实现可以多样，治理接口必须可互操作。这样既避免平台垄断创新，也避免不同团队形成无法管理的孤岛。

八、落地路线图：用一年时间从 Agent 项目群走向生产体系

路线图先解决可见、可控、可回放，再扩大自治和组织学习；顺序比组件数量更重要。

（一）0---90 天：先建立可见性和最小安全底座

1、0---30 天：盘点与分级

发现所有已建、在建和外购 Agent，登记所有者、用途、模型、工具、数据、记忆、部署环境与成本；按数据敏感度、动作可逆性、影响范围和自主程度分级。优先处置共享凭证、无所有者、生产写权限和无法停用的 Agent。

同时选取两到三个代表性流程：一个只读知识场景、一个可逆写场景、一个长时多步骤场景。它们将用于验证公共底座，而不是一次覆盖全企业。

2、31---90 天：建立黄金路径

建设最小 Agent Registry、独立身份、工具白名单、统一 trace、基础离线评估、人工审批和 kill switch。规定所有新 Agent 必须通过注册和发布门禁；高风险动作默认禁止，除非有明确策略与审批。

在知识侧，为试点域指定权威源与知识负责人，保留 ACL、版本和引用；在记忆侧先从结构化检查点和用户可见偏好做起，不急于开放自动程序学习。早期最重要的是建立可回放与可撤销性。

（二）3---6 个月：把任务、知识和评估连成闭环

1、建立统一任务状态与跨系统证据链

为长任务引入任务对象、幂等键、检查点、补偿和可恢复执行；让 Agent、工具、策略和人工审批共享 Task ID 与 Trace ID。统一观测字段，建立质量、成本和风险仪表盘。

2、从文档 RAG 升级为知识供应链

引入混合检索、重排序、权限过滤、来源验证和知识新鲜度事件。把在线失败按"知识缺失、检索错误、生成错误、工具错误、策略错误"分类，自动进入问题库和评估集。此阶段应能回答：某个错误来自哪一层，修复哪一层最有效。

（三）6---12 个月：扩大自治，但以恢复性和学习门禁为前提

1、建设多层记忆与经验发布机制

在明确作用域与 TTL 的前提下上线语义记忆；从高质量、可验证轨迹中提取候选程序经验；通过回放、沙箱与灰度测试后发布为技能、策略或提示版本。建立用户查看、纠正、遗忘以及知识负责人审核机制。

2、开展持续红队与级联故障演练

测试提示注入、记忆投毒、恶意工具描述、权限升级、跨 Agent 欺骗、循环调用、下游超时和批量误操作。演练身份吊销、任务冻结、索引回滚、记忆隔离与补偿恢复。把恢复时间与残余影响纳入 SLO。

（四）六个常见反模式

1、先接所有工具，再补权限

这会让试点中的临时权限固化为生产事实。正确顺序是先定义任务与动作边界，再按最小权限接入工具。

2、把所有对话都叫记忆

原始历史不是长期知识。没有筛选、冲突处理、TTL、来源和删除能力的"记忆"，只是越来越昂贵且危险的日志副本。

3、只监控最终回答

最终回答无法解释中间越权、无效循环和工具副作用。必须对整条轨迹观测，并关联业务结果。

4、用一个总体分数决定上线

平均分会掩盖高严重度失败。发布门禁应按风险分层，并对关键场景设置零容忍或硬阈值。

5、把协议互通误认为安全互信

A2A、MCP 和 OpenTelemetry 降低互操作成本，但身份、权限、数据边界与供应链信任仍由企业负责。可连接不等于可授权。

6、把人工审批当作万能兜底

如果审批频繁、信息不足或动作不可变性缺失，人会形成点击疲劳。审批必须聚焦少量高影响节点，并提供充分证据；其余风险应由确定性策略、沙箱、预算和最小权限承担。

九、结语：Agent 的下一轮竞争，是组织把智能变成制度的能力

Agent 单点能力还会继续增强，但模型升级不会自动带来企业生产力。真正的复利来自另一件事：每一次运行都可观察，每一次失败都能归因，每一条经验都经验证后沉淀，每一份组织知识都带着权限与来源进入上下文，每一个真实动作都在身份、策略、预算和恢复机制之内发生。

这套能力可以被称为 Agent Platform、Agent Control Plane、Agent Mesh，也可以称为 Agent Operating System。名称不是重点。重点是企业开始把 Agent 视为一种新的生产主体：它有身份证、有产品负责人、有工作合同、有可用资源、有记忆边界、有行为记录，也有必须遵守的组织制度。

未来优秀的企业 Agent，不一定是最"自主"的 Agent，而是能够在需要时自主、在不确定时停机、在高风险时升级、在失败后恢复、在长期运行中学习，同时始终能够说明"我为什么知道、为什么这样做、谁授权我这样做"的 Agent。

当企业做到这一点，Agent 才真正从演示中的聪明个体，变成生产系统中的可靠组织能力。