企业如何搭建Agent运行底座？从多Agent互操作到安全执行

2026年以来，一些过去被Agent框架内部消化的问题，开始被单独提到运行时层面讨论。行业把AI Runtime Infrastructure定义在模型之上、应用之下，用它观察长任务的状态，并在任务偏离、资源异常或策略变化时介入；A2A协议进入1.0版本后，Agent发现、任务状态和结果交付有了更明确的协议对象，OpenTelemetry也在补充Agent与工作流的可观测语义。多Agent进入企业时，架构讨论已经不能只停留在“哪个Agent效果更好”，还要回答不同Agent怎样被发现、调用和追踪。

这给企业自建Agent平台提供了一个新的思路。运行底座不必要求各部门改用同一种框架，也不必把所有任务搬进同一种计算环境。平台可以先统一Agent参与企业运行时必须遵守的几份契约，再用适配器连接现有Agent。部门保留开发自由，平台团队获得可执行的管理边界。

统一框架很难，统一运行契约更现实

企业里的Agent通常不会来自同一个技术栈。一个团队使用开源框架开发研究Agent，另一个团队采购行业Agent，部分员工还会在桌面端运行本地助手。要求它们共享内部代码和编排方式，迁移成本很高，也容易让平台建设卡在框架选型上。

运行底座更适合统一外部行为。Agent怎样声明自己的能力，接到任务后如何回报状态，以什么身份访问工具，执行过程怎样进入监控，这些内容可以形成稳定接口。当前公开规范已经给出了一些可参考的对象：

把这些边界固定下来，平台才有可能接管运行过程。至于Agent内部使用什么模型、怎样规划任务、是否采用多Agent编排，仍由开发团队决定。企业不需要先消除所有框架差异，只要求接入的Agent在边界处提供可验证的输入和输出。

Agent清单要能被机器读取

A2A 1.0规范使用Agent Card描述一个Agent的身份、能力、Skill、服务端点和认证要求。客户端在调用前先读取这张卡片，确认对方是否支持流式响应、异步通知或扩展能力。需要认证才能查看的详细信息，还可以通过Extended Agent Card按身份返回。

企业内部未必直接采用A2A，但Agent注册表可以借鉴这种方式。每个Agent提交一份机器可读清单，其中写明负责人、版本、可处理的任务、接入地址、认证方式和支持的交互模式。平台根据清单生成调用适配器，并在Agent升级时检查兼容性。

清单里不应保存静态密钥。它只声明认证要求，调用方通过身份系统另行取得凭据。这样，Agent信息可以进入企业目录并被其他Agent发现，凭据仍然按照人员、租户和任务动态发放。某个Agent下线或版本存在问题时，平台停用对应清单即可阻止新的任务分配，不需要逐个修改上游Agent的Prompt。

任务协议要从聊天会话中独立出来

对话系统习惯把一次交互理解成消息请求，Agent更常遇到长时间运行和中途等待。A2A将Task定义为带有唯一标识的有状态工作单元，并区分已提交、执行中、完成、失败、取消、等待输入、等待认证和拒绝等状态。任务还可以持续产生Artifact，用来传递文档、文件引用或结构化结果。

这些状态比“成功或失败”多了一些，但能减少多Agent协作中的误判。资料收集Agent需要访问受限系统时，可以返回AUTH_REQUIRED，上游Agent不必把它当作失败任务重新创建；法务人员需要补充合同附件时，任务进入INPUT_REQUIRED，已有Artifact和历史记录继续保留。补充条件满足后，原任务接着执行。

企业运行底座可以把这套任务语义映射到内部状态机。一次任务在多个Agent之间转交，task_id与context_id继续保持关联；子Agent产生的Artifact回到父任务后，平台记录版本和来源。执行节点重启或用户暂时离线，任务状态仍然保存在运行底座里，不依赖某个进程或聊天窗口。

任务协议还要明确取消的含义。数据库中把状态改成CANCELED并不会自动停止脚本，上游Agent也可能继续等待结果。调度器发出取消命令后，执行节点需要终止相应进程，关闭工作区写权限并回报最终状态。只有完成这些动作，取消才算结束。

Agent身份要分成入站和出站

员工调用Agent时，平台要识别发起人和所属组织，这是入站身份。Agent随后访问代码仓库、内部接口或第三方服务，还需要一份出站身份。两类身份混在同一个固定服务账号里，平台只能查到“某个Agent调用了工具”，很难还原实际授权来源。

Amazon Bedrock AgentCore的安全文档给出了一个值得关注的工程提醒：网关策略只有在全部流量经过网关时才有效，如果调用方可以直接访问Runtime，策略、Guardrail和拦截器都会被绕过。文档同时建议把OAuth凭据和API Key交给身份组件管理，避免凭据进入Agent代码或日志。

企业自建运行底座时也要处理这条旁路。工具网关负责校验调用者和目标工具，Runtime只接受来自网关的请求；Agent根据当次任务取得短期凭据，工具调用结束后凭据失效。业务系统继续做最终鉴权，网关不复制一套业务权限。这样既能保留现有身份体系，也能阻止Agent绕开平台直接连接工具。

多Agent转交任务时，身份不能只传一个用户名。父Agent需要传递委托范围，子Agent获得的权限不得超过原任务。发生再次委托时，平台保留委托链和有效期。某个子Agent即便具备更强的工具能力，也只能在这次任务允许的范围内使用。

可观测数据也需要公共语义

多Agent平台常见的另一类问题是日志无法拼接。Agent A记录“已委托”，Agent B记录“开始处理”，工具网关只留下一个HTTP请求，运维人员很难判断三条记录是否属于同一项任务。

OpenTelemetry的GenAI Agent语义规范正在定义invoke_agent、invoke_workflow和plan等Span，并为Agent ID、Agent版本、会话ID和错误类型提供统一属性。一次多Agent任务可以由Workflow Span统领，下挂Agent调用和工具执行，平台再用Trace ID关联业务日志。

这项规范目前仍标记为Development，字段和命名可能继续变化。企业可以先做内部映射层，不要把尚未稳定的字段直接固化为数据库主键。采集内容也要受数据策略控制：任务标识、耗时、错误类型和工具名称通常可以进入遥测系统，原始Prompt、文件内容和工具返回值则应按敏感级别决定是否记录。

统一观测语义的价值会在故障时体现出来。上游Agent等待超时，平台沿Trace ID可以看到子Agent已经完成规划，但工具调用被身份网关拒绝；修复权限后，只重放失败步骤，无需重新执行整条工作流。

安全执行是运行协议的最后一段

A2A负责Agent之间怎样协作，OpenTelemetry负责怎样记录调用链，它们都不直接限制进程能够读取哪些文件或访问哪些网络。任务进入执行节点后，仍然需要安全执行环境落实策略。

凡泰AI的产品体系把这两部分分开处理。FinClaw承担企业Agent中台的运行管理，将租户、数字员工、Skill、运行实例和工作区纳入同一平台，保存任务进度和执行记录。不同来源的Agent可以通过适配器进入平台，具体采用哪种协议则由项目接入方式决定。

FinSafe处理代码执行与高风险工具调用。中心端可以在企业内网提供Sandbox as a Service接口，本地端用于必须处理终端文件的任务。策略随执行请求进入沙箱，约束可读写目录、网络和资源；执行结果连同策略版本返回管理侧。FinClaw知道任务由谁发起、交给哪个Agent以及运行到了哪一步，FinSafe记录实际动作在哪个边界内完成。

现有IAM继续提供人员身份，业务系统保留最终鉴权，MDM负责终端分发和设备状态。运行底座利用这些系统提供的结果，不需要把企业原来的安全体系再造一遍。

用两个异构Agent测试运行底座

运行底座的第一项测试，可以选择两个技术栈不同的Agent完成一次任务交接。例如合规Agent接收材料检查任务，把证据收集交给文档Agent；文档Agent访问受限文件时返回等待认证，员工完成授权后继续处理，并把结构化Artifact交回合规Agent。最后一步进入沙箱执行，生成结果文件但不直接写回业务系统。

这条任务可以验证四个容易被普通演示忽略的分支：

完成这轮测试，企业才能确认运行底座管理的是Agent之间的运行关系，而不只是若干服务实例。后续接入新Agent时，平台检查能力清单、任务协议、身份方式和遥测映射；高风险执行再进入统一安全边界。Agent框架可以继续变化，企业的调用规则和运行记录不会跟着某个框架一起丢失。

给框架变化留出余地

从这些公开规范可以看到，企业Agent平台正在补齐一套独立于具体框架的运行协议：能力声明用于发现Agent，任务状态支撑长时间协作，入站与出站身份限制委托范围，可观测语义负责串联跨Agent调用，安全执行环境则约束最终落到系统上的动作。

这些标准仍在演进，企业没有必要等它们全部稳定，也不宜把某一份草案直接做成内部数据库结构。运行底座可以保留协议适配层，把外部规范映射到企业自己的Agent目录、任务状态和审计模型。这样做不追求一次选对永久不变的框架，而是让更换Agent框架或升级协议时，已经接入的业务流程和历史运行记录不必重新建设。