企业内部引入多个 Agent 后，问题往往不再是“有没有助手”，而是这些助手能否安全地共享知识、调用能力并协同完成任务。写材料的通用 Agent、查询制度的知识 Agent、处理工单的流程 Agent，可能各自有效，却容易形成新的信息和能力孤岛。
一个面向企业的 Agent 平台，重点不应只是再提供一个聊天入口，而是建立一层可治理的连接能力：统一接入不同 Agent，按权限提供上下文，持久化任务状态，并把涉及业务写入的动作交给审批和执行系统处理。
企业 Agent 平台应该解决哪些问题
接入统一，但不强行统一内部实现
不同 Agent 可以继续使用各自的模型、提示词和运行框架。平台需要统一的是接入后的公共能力，包括：
- 发现可用的 Agent、Capability、Skill、Prompt 和 Tool
- 获取当前身份有权访问的知识与团队经验
- 创建、查询、取消和恢复异步任务
- 进入固定的工作流
- 在策略允许的范围内调用业务执行服务
REST、MCP 和受限的 A2A 都可以作为接入方式。请求进入平台后，应经过身份、Workspace、权限和能力版本校验，再交给 Runtime、Workflow 或具体业务服务处理。
需要特别区分协议和授权。协议字段本身不会产生权限，Workspace 的父子关系也不应自动授予跨空间访问权。直接用户身份、受限的 Agent 委托身份以及跨 Workspace 查询，都应有各自明确的边界。
能力需要可发现、可版本化
让每个 Agent 通过提示词记住其他 Agent 的全部接口，维护成本很高。更适合的方式是建立带版本的能力目录：调用方先搜索自己有权查看的能力，再读取指定版本的调用说明。
任务创建时绑定实际使用的能力版本，可以避免目录更新后，旧任务在不知情的情况下切换到另一套行为。工具合同也应限定输入字段和用途，不应因为接入了 MCP 或 A2A，就开放任意脚本执行、审批决策或直接写业务表。
这对选型有一个直接影响：个人站长或小团队如果只是部署单一问答 Agent，能力目录和多协议适配可能属于额外复杂度；当团队开始同时维护多个 Agent、多个业务系统和多个权限域时，统一能力注册才更有价值。
上下文共享与任务管理
读取资料不等于获得操作权限
企业资料通常分为正式知识、个人经验、团队经验和待审核的改进候选。平台在提供上下文时，需要同时检查身份、Workspace、来源版本和当前授权，并保留引用、内容哈希以及预算信息。
资料撤回或失效后，新任务应重新进行校验，不能长期依赖旧快照。多来源查询可以帮助 Agent 汇总多个获准空间的资料，但它不应自动变成跨 Workspace 执行任务。
读取与执行必须分开。Agent 可以查到服务规范，并据此生成工单草稿，但这不表示它能够直接创建工单；Agent 生成的回答也不应自动写回知识库或长期记忆。
把工作从聊天记录中独立出来
适合企业协作的 Agent 平台，需要把一次工作建模为持久化 Task，而不是只保留在会话窗口中。调用方可以用任务 ID 查询状态和结果，系统则记录排队、执行、终态、用量和相关运行信息。
实际实现通常还需要处理以下边界：
- 队列容量和 Workspace 配额
- 并发执行槽
- 任务取消与恢复
- 网络中断后的幂等重试
- Worker 租约和节点故障接管
“请求已受理”和“任务已完成”是两个不同状态。如果创建请求后网络中断，调用方应沿用原有的幂等身份查询或重试，避免重新生成任务。任务真正开始执行时，还应再次检查权限、能力版本、资料来源和预算。
业务动作必须经过受控流程
模型可以提出建议，但不应直接拥有业务系统的最终写入权。涉及状态变更的动作，通常需要经过 Policy、Approval、Credential 和 Execution 等环节，外部连接器则应限制用途并支持结果回读。
例如，Agent 可以根据故障描述准备服务请求，也可以补齐表单字段，但只有在用户确认、策略检查和审批条件都满足后，流程才进入登记操作。外部 CRM 或服务台连接器可以默认关闭，在本地开发阶段使用 loopback 替身验证流程。
一个更容易审计的协作链路可以是：
- 用户在指定 Workspace 中创建资料分析或请求准备任务。
- Runtime 按当前授权读取知识与团队经验，并记录来源版本。
- Agent 生成带引用的准备结果，需要补充资料时仍受查询范围限制。
- 用户确认内容后，任务进入策略、审批和执行环节。
- 业务登记成功后，Workflow 创建人工工作项并分配负责人。
- 人工提交处理结果，Workflow 保存交接信息并汇总结果。
这种模式把职责拆开：Agent 负责准备，人工负责需要判断的处理，Workflow 负责状态交接。只读 Agent 不因参与流程就获得任意工具或业务写入权限。
对于批量请求，也应设置明确上限。例如同一 Workspace 的批次可以限制总项目数和同时运行数，每项使用固定的只读知识分支，最后再做确定性汇总。受控并行比无限扩展 Agent 数量更容易预测资源消耗和结果质量。
经验沉淀要可追溯、可审核
把所有历史内容塞进共享提示词，容易带来过期信息、来源不清和错误扩散。更稳妥的做法是分层管理：
- 个人经验：由个人整理和控制，不自动升级为团队资料
- 团队经验卡：由 Owner 维护、审核、发布和撤回
- 正式 Knowledge：保留文档版本、片段和引用关系
- 改进候选：处于隔离状态，不能直接进入普通任务上下文
经验候选可以先经过事实审核，再使用开发集和保留集比较效果，最后由人工批准并由负责人发布。候选内容需要可回滚，来源和变更过程需要可追踪。模型生成了更好的文本，并不意味着它已经具备成为团队知识的资格。
评测数据也应与普通任务隔离。固定场景可以使用版本化的合成数据和独立答案哈希，报告记录能力版本、结果呈现和调用用量，但不能让 Agent 在运行普通任务时读取预期答案。这样的检查能够验证隔离与流程是否按设计运行，却不能直接证明真实员工效率或模型质量已经提升。
关键工程实现怎么取舍
虚拟线程负责承载，不负责限流
Agent 任务通常会等待数据库、模型服务或业务系统响应。JDK 21 虚拟线程可以降低阻塞式调用的线程成本，但不能替代并发治理。实际系统仍需要结合 Semaphore、执行槽、持久队列上限、Workspace 配额和模型供应商并发限制控制负载。
判断云服务器配置时，应把并发任务数、单任务等待时间、模型接口限制和数据库连接池一起考虑。单纯增加应用线程数，并不会自动提高外部模型或业务系统的承载能力。
多节点任务协调依赖持久化存储
多个 JVM 共同消费任务时，可以使用 PostgreSQL 作为共享队列。Worker 通过 FOR UPDATE SKIP LOCKED 领取不同任务，并配合租约和递增 fencing token，防止旧节点在任务已被接管后覆盖新状态。
模型 Provider 的并发槽也可以放在 PostgreSQL 中统一协调。租约失效后，槽位应先进入隔离状态；只有确认原请求已经结束，才能重新释放额度。这样可以降低“本地心跳丢失但远端请求仍在执行”造成的超配风险。
词法检索与向量检索互补
企业知识查询通常同时需要关键词精确匹配和语义相似检索。PostgreSQL 词法检索适合明确术语、编号和专有名词，pgvector 则适合查找表达不同但含义接近的内容。
向量索引不能只依赖维度判断兼容性，还应记录向量 Provider、模型修订、维度和距离度量等配置签名。进入上下文的资料则需要保留文档版本、索引构建信息、片段和内容哈希，输出中保留引用，方便排查 Agent 到底使用了哪些依据。
如果团队规模较小、知识量有限，可以先从 PostgreSQL 和简单权限模型开始；当资料规模、更新频率或检索隔离要求提高后，再评估独立向量数据库或专门搜索服务。
协议适配层不应绕过业务规则
MCP 可以用于暴露能力发现、Skill 详情、授权上下文和异步任务入口；A2A 可以用于受限的 JSON-RPC/HTTP 任务交互。无论入口是什么，都应进入统一的 Identity、Task、Policy 和 Execution 服务。
协议适配层负责处理客户端差异，不能成为权限绕过层。实际落地时，可以先支持固定工具合同、纯文本消息、任务读取、取消和有限的跨 Agent 交互，再根据真实需求扩展附件、多轮输入或流式推送。宣称兼容所有 Agent，通常不如明确支持的合同范围更便于维护和验证。
幂等、写入和能力导入
外部系统写入时，平台需要保存稳定的 operationId。如果请求超时或连接断开，应先用原操作标识查询结果，而不是换一个 ID 再次提交。内部 Task 的租约和 fencing 只能保护平台状态，不能替代对外部副作用的查询确认。
能力资料包也应只携带说明，不携带权限。导出的 Capability 或 Skill 描述可以包含结构、版本和内容哈希，但不应包含认证信息、模型密钥、可执行脚本或隐含的 Prompt 权限。导入后保存为当前用户可读的私有只读资源，真正调用时仍在线检查版本、身份和授权。
适合谁采用这类平台
企业 Agent 平台更适合以下场景：
- 团队已经存在多个 Agent，需要统一发现和调用能力
- Agent 需要访问分层知识库，并遵循 Workspace 权限
- 任务会跨越模型调用、人工处理和业务系统写入
- 团队需要审计任务状态、资料来源和外部操作结果
- 经验沉淀必须经过审核、发布和撤回
如果只是个人博客问答、单一客服机器人或一次性脚本，直接使用模型 API、轻量工作流和对象存储可能更简单。引入完整平台前，应先估算权限域数量、任务并发、数据敏感度、外部写入需求和运维能力，避免为了“多 Agent”而承担不必要的基础设施成本。
本地验证与部署提示
这类平台可以先在本地验证核心机制：使用 JDK 21、Docker Compose 和 PostgreSQL，模型层采用 deterministic 替身，不调用真实模型服务。应用由 Maven Wrapper 启动，数据库由 Compose 提供，健康检查可通过 Spring Boot Actuator 暴露。
本地压测可以检查多 JVM 消费同一任务队列、任务租约、权限隔离、固定 MCP/A2A 合同、来源撤回、人工工作项以及审批后的 loopback 写入。但单机、隔离数据库和替身模型得到的吞吐，只能说明该测试条件下的调度表现，不能推导生产环境容量，也不能证明真实模型质量或企业工作效率。
部署到云服务器时，需要进一步评估 PostgreSQL 高可用、队列积压、模型接口限流、密钥托管、日志脱敏和跨区域网络延迟。对象存储适合保存版本化文档和评测产物，CDN 更适合分发静态管理界面，不应直接暴露包含权限判断的任务接口。