去年年底我帮团队搭了一个内部的 AI Agent 平台上线跑通之后部门里陆续有十几个 Agent 在干活有写周报的、有跟客户催资料的、有盯监控告警的、有做数据报表分析的。有个同事当时说了一句话我一直记到现在“这不就是公司批量招了一批 AI 同事嘛。”这句话点破了一件事。很多人觉得 AI Agent 是个很酷的“单点技术”写个 Prompt、配几个工具、调一次大模型就能跑起来。但真到了企业里事情完全不是这样。一个 Agent 跑通叫“手工作坊”一百个 Agent 稳定协作、互相调用、按权限隔离地跑才是“工厂”。这篇文章想聊的就是从 0 到 1 搭一个企业级的 AI Agent 平台——不是教你写某个 Agent 的 Prompt而是把整套“造 AI 同事”的流水线讲清楚。适合读这篇文章的人大概是三类正在做企业级 AI 应用的架构师和后端研发想把 AI 能力落地到公司内部系统的技术负责人以及已经有几个 Agent Demo 但不知道怎么平台化、怎么管起来的人。1. 为什么是“工厂”而不是“手工作坊”先想清楚 Agent 平台的必要性1.1 手搓 Agent 的爽与痛我最早给业务部门做智能助手的时候也是手搓。写一个 Java 的调度类在方法里硬编码调大模型接口把 Prompt 拼进去再写一堆 if-else 处理工具调用。单个跑起来确实爽业务同学说“这个好智能”我又赶紧复制了七八个类似的“智能助手”。然后问题就来了。首先是重复建设。每个 Agent 都要重新做一遍 Prompt 模板、工具连接、上下文管理、错误重试这些东西长得几乎一模一样但代码散落在各自的业务系统里。其次是维护地狱。大模型接口升级了要改七八处某个工具的鉴权方式变了要改更多处线上 Token 成本突然飙高你也说不清到底是哪个 Agent 哪段 Prompt 在烧钱。最要命的是协作。业务方提需求说“让这个 Agent 查完订单之后自动把结果告诉那个 Agent”我只能在代码里硬写一段跨模块调用没有任何统一的契约。那一刻我意识到单个 Agent 好做Agent 体系难做。难就难在它没有标准化、没有复用、没有治理。而这三个词恰恰是“工厂”和“手工作坊”的本质区别。1.2 Agent 工厂的三个核心价值复用、标准化、协作后来我们搭平台技术方案换了三轮但有一件事始终没变平台要解决的从来不是“模型调得好不好”而是三件事。第一是复用。技能Tool、连接器Connector、Prompt 模板、知识库切片这些做成标准组件之后新的 Agent 可以通过配置组合出来而不是重新写一遍。复用的收益不是省代码量而是省调试时间。企业里最贵的永远是人的时间。第二是标准化。所有 Agent 必须走统一的声明、注册、鉴权、监控流程。什么叫声明就是你得先定义一个 Agent 的名字、职责、绑定哪些技能、允许调哪些工具。标准化之后平台才能自动生成文档、自动做安全检查、自动算成本和频率。第三是协作。企业里的 AI 同事不会单独存在。一个“订单查询 Agent”查完数据之后需要把结果丢给“异常分析 Agent”去判断这个订单是否异常。这就需要一个平台级的消息和任务编排机制而不是靠 Developer 手动 glue。平台存在的意义就是把这三点固化下来。哪怕你只有两三个 Agent只要你想往企业级走这些能力早晚都要补。1.3 什么时候你可以先不上平台我也想把话说清楚不是所有场景都需要上平台。如果你只是个人开发者、或者做一个 Demo 给朋友看直接调 API 就行上平台就是过度设计。但如果你满足下面任意一条我建议你认真地考虑平台化公司里有多个业务系统要把 Agent 集成进去同一批大模型 API 或企业知识库要被多个项目共用有非技术同学运营、客服、业务分析师也想配置自己的智能助手需要统计每个 Agent 的成本、调用量、成功率有多个 Agent 需要互相协作或者被统一的工作流调度。一两个 Agent 时你会觉得平台是负担五个以上时你会觉得没有平台根本管不住。2. 工厂流水线的第一张图纸Agent 平台五层架构与职责边界想清楚为什么之后就是怎么搭。我复盘了我们最终跑通的架构核心是五层。每一层做该做的事绝不越界。2.1 编排层把“拆任务-定顺序-出结果”变成流程编排层是整个平台的大脑。它的职责是把用户发来的复杂任务拆解成子任务决定子任务由哪些 Agent 执行、执行的顺序、结果的汇总方式。这一层是很多初学平台设计的人最容易搞混的地方。有人把编排逻辑写死在每个 Agent 内部结果每个 Agent 都像一个小型工作流引擎互相嵌套最后根本无从排查。我们的做法是编排层只负责流不负责算。编排层定义节点、边、条件和超时策略真正的“算”由执行层完成。我举一个例子。用户问“帮我查一下上个月华北区的销售异常订单”。编排层会拆成三个子任务首先查销售明细然后判断异常标准最后生成分析报告。中间如果“查销售明细”超时就触发降级策略跳过明细直接基于汇总数据做分析。这些逻辑都在编排层配置Agent 本身不需要关心自己在链路上的位置。2.2 执行层与工具层技能注册、参数校验与沙箱运行执行层是“发动机舱”。它负责真正调用 Agent 对应的模型、加载记忆、执行工具调用。工具层跟在执行层下面是所有外部能力的统一出口。工具层有个特别重要的设计原则所有工具都必须经过注册和参数校验才能被 Agent 调用。我们内部把工具定义成一个标准契约包括工具名称、描述、入参 Schema、鉴权级别、超时时间、幂等标志。Agent 只能按 Schema 传参平台负责校验格式、权限和频次。为什么这么较真因为大模型在调用工具时天生会“自由发挥”。你不给它硬性 Schema它就会传一些不存在的参数进去或者把参数类型搞错。有一次我们的 Agent 调订单查询接口直接把日期字段传成了字符串 “_latest”把同事吓得够呛。从那以后所有工具参数一律强制用 JSON Schema 校验不合法就回退让模型重新生成参数最多重试三次。沙箱运行这点也很重要。凡是 Agent 要执行的代码类工具不能再直接跑在业务服务进程里。我们内部做了一个轻量的沙箱层把 Python、JavaScript 这类动态执行任务放到独立的进程组里限制 CPU、内存和文件写入范围。虽然不是完全虚拟机隔离但已经能挡住绝大多数“Agent 跑飞了”的意外。2.3 记忆层短期上下文和长期知识库的分工很多 Agent 平台把记忆简单理解成“多轮对话记录”这是不够的。企业级场景下记忆分两种职责完全不同。第一种是短期上下文。这是模型在单次任务内需要的信息比如用户刚才提到的订单号、日期范围、筛选条件。短期上下文该怎么管我们的经验是采用分层摘要机制。不要把所有历史消息一股脑塞进 Prompt而是每轮对话结束之后用模型生成一个结构化摘要只保留关键实体和用户最新意图。这样既不影响模型理解也把 Token 成本压下来。第二种是长期知识库。企业里的知识是结构化的规章制度、历史方案、产品文档、故障复盘。这类知识我们走检索增强RAG路线先把文档切片、向量化、建立索引任务执行时通过召回相关片段注入上下文。这里有个很多人踩过的坑RAG 不是把知识库一建就完事。切片粒度、召回数量、重排序策略、上下文注入位置直接决定 Agent 回答的专业度。我们后来固化了一套“三段式”先粗召回前 20 个切片再用重排序选出最相关的 5 个最后把 5 个切片注入上下文。效果比一开始“一股脑召回 20 个切片”稳定得多。2.4 接入层让业务系统以统一方式调用 Agent接入层是给企业内的各个业务系统用的。无论你是 Java 后端、前端页面还是钉钉/飞书这类办公协同工具都通过统一网关调用平台能力。网关统一处理鉴权、限流、审计和路由。这一层不用写太多代码但设计上有个关键点必须做异步任务支持。Agent 执行一个复杂任务可能要几十秒甚至几分钟业务系统不能干等。我们提供了两种调用模式同步短任务模式适合问答类和快速计算异步长任务模式任务创建后返回 TaskId业务系统通过回调或者轮询获取结果。接入层的存在让平台变成了一个内部的技术中台。业务方不需要关心底层模型是什么、技能怎么实现他们只需要拿到一个 API 或者一个 UI就能把“AI 同事”接进自己的业务流程。3. Java 技术栈下的平台底座从选型到落地的一次复盘3.1 为什么我们坚持用 Java 生态聊完架构聊聊实现。很多人一听到 AI Agent第一反应是用 Python因为网上大部分 Agent 框架都优先支持 Python。但在企业级落地上我们最终选择了 Java 生态原因很现实AI 平台要接的东西全是 Java 的。我们公司内部有订单系统、ERP、CRM、监控平台清一色的 Java 技术栈。平台如果要对接这些系统用 Java 做是最顺的。共享内部 SDK、复用已有的中间件、对接统一鉴权体系都省事。而且 Java 生态的稳定性、内存模型、并发工具、运维体系在企业里经过长期验证比“为了算法爽而用 Python”靠谱得多。当然也不是说 Python 不能做。如果你是从零开始、业务系统本来就很松散、团队全是 Python 背景那用 Python 没问题。但如果你是“企业级 Java 应用平台”这个思路我建议踏实走 Java。3.2 模型调用的统一抽象别让业务代码碰 SDK搭建平台时第一件要做的就是把模型调用抽象出来。我们内部定义了一个ModelGateway接口屏蔽掉不同大模型厂商之间的差异。业务代码只依赖自己的接口不直接引用任何模型的 SDK。模型网关里做了几件事模型路由、超时控制、重试、降级、内容审核和成本记录。模型路由是我觉得特别有用的一个设计。同样的任务用户想要快答案就走轻量模型要做复杂分析就走长推理模型要处理文档就走多模态模型。平台根据 Agent 声明时的modelPref属性自动路由不需要业务方感知。另外大模型调用必须有超时和熔断。曾经有一款模型服务不稳定接口经常卡住我们的 Agent 任务也跟着全部积压。后来在网关层加了基于信号量的并发限制和基于错误率的熔断器超过阈值就快速失败并切换到备用模型。这个能力单体 Agent 根本不需要但平台一天几百个任务的时候它决定你系统的生死。3.3 一个最小化的 Agent 定义与执行骨架下面这段是我们在平台里实际使用的核心概念的简化版本。它不是完整框架代码而是让你理解 Agent 在平台里是怎么被“定义”和“执行”的。// Agent 的标准定义声明这是一位“AI 同事” AgentComponent(name weeklyReportAgent, version 1.2.0) AgentProfile( displayName 周报助手, description 负责收集各团队周报并汇总生成部门周报, modelPref fast ) public class WeeklyReportAgent { AgentSkill(name weeklyReport.generate, description 根据指定时间段生成部门周报) public String generateReport(Param(teamIds) ListString teamIds, Param(startDate) String startDate, Param(endDate) String endDate) { // 业务逻辑拉取数据 - 整理 - 调用模型生成 - 返回结果 return report; } }这个骨架要表达的核心思想有三个。第一Agent 是“声明式”的。平台启动时会扫描所有AgentComponent把 Agent 的元信息注册进系统包括它挂载在哪个空间、属于哪个团队、调用频率限制是多少。声明之后Agent 自动获得 API 路由、监控埋点、成本核算不需要额外写代码。第二技能是显式的。Agent 有哪些能力、参数是什么、参数类型是什么全部写清楚。平台在运行时可以根据这些定义生成“能力说明书”也能在编排层自动判断一个子任务应该路由给谁。第三Agent 和业务代码解耦。Agent 本身不直接调模型所有模型交互走ModelGateway不直接调外部接口所有外部依赖走 Tool 层注册的ToolClient。这样当模型厂商切换、接口鉴权变更时Agent 代码几乎不用动。3.4 基础组件清单别在平台起步时重复造轮子搭建平台时有一些基础组件是可以直接复用的不用自己重写。配置中心所有 Agent 的模型偏好、Prompt 版本、技能开关都放在配置中心管理支持动态下发和按环境隔离。注册中心与网关内部服务发现和统一路由Java 生态可以直接用现成的 Nacos 或 Eureka 搭配 Spring Cloud Gateway。消息队列编排层的异步任务流转需要用 MQ 解耦。一边是任务生产者一边是 Agent 执行消费者用 MQ 天然支持削峰填谷。分布式任务调度定时触发的 Agent 任务比如每天早上 9 点生成前一天的销售简报需要一个任务调度平台。向量数据库长期知识库需要存储和检索向量。选型时重点看三样检索性能、过滤能力租户隔离很依赖 metadata 过滤、运维成本。指标监控与日志所有 Agent 的调用量、延迟、成功率、Token 消耗都要有数。没有这些平台上线之后就是一锅粥。这些组件不是 AI 特有的但它们组合起来才是平台的地基。地基没打好后面加再多花哨功能都白搭。4. 造“AI 同事”的第一步把岗位说明书写清楚4.1 人设 Prompt 模板的三件套职责、边界、风格上了平台造一个 Agent 反而变得简单了因为平台提供了一套标准化的“岗位说明书”模板。这个模板是我觉得整个平台最值钱的地方之一。它分成三块。首先是职责。职责要写“这个同事具体负责什么”。写职责的关键是具体到动词和对象比如“负责查询各销售区域的实时订单量和销售额并按需求生成 Excel 图表”而不是“负责处理销售数据”。其次是边界。边界是防止 Agent 乱跑的最有效手段。比如“只能查询近 90 天的数据”“不做预测建议”“当用户要求删除数据时必须转人工”。模型在边界清晰的情况下胡编乱造的概率会大幅下降。最后是风格。风格决定了它输出的“质感”。比如“使用简洁的列表式表达”“不做寒暄”“所有结论必须附数据来源”。风格不是可有可无的装饰它在业务场景里直接决定信息的可信度和可读性。4.2 技能与权限的绑定安全的第一道闸门岗位说明书写清楚之后还有一个更硬的东西权限。在“造 AI 同事”的场景里权限往往比 Prompt 更重要因为模型可能被诱导做出越权行为。我们的做法是Agent 声明里显式绑定“可执行工具列表”和“数据空间范围”。比如一个“报表助手”Agent我们可以给它绑定“订单查询-Tool”和“报表生成-Tool”但不绑定“删除-Tool”和“用户信息修改-Tool”。空间范围也很重要比如它只能访问销售一部到五部的数据看不到其他区域的敏感数据。这个设计对开发人员来说可能是基本常识但对企业业务同学来说影响巨大。因为 Agent 一旦跨权限操作哪怕只发生一次都会造成难以估量的信任损失。4.3 记忆与知识接入RAG 的落地节奏岗位说明书里还应该说明这个“同事”拥有什么知识。我们平台的实践是先跑通通用模型再逐步接入企业知识库。一开始Agent 对公司的内部制度、产品手册、历史方案是完全不了解的。你让它“查一下去年做过类似的活动复盘”它只能瞎编。接入了 RAG 之后它的回答质量和可信度肉眼可见地提升。但我想明确一点RAG 不是一次接入就一劳永逸。知识库需要持续的“数据治理”。过期的文档要下线、冲突的文档要合并、格式不好的文档要先清洗再切片。我们专门定了一个“双周知识维护”的流程每两周由业务同学和研发同学一起过一遍新增文档、分析一次 Agent 回答中“知识缺失”的反馈记录然后决定是否补充切片或调整检索策略。5. 企业级上线最容易翻车的五个场景平台搭到这一步功能上已经像模像样了。但真正让很多团队倒在半路的往往不是技术选型而是以下几个看起来不起眼的细节。我把它们单独列出来因为每一个我都踩过。5.1 多人共用一个 Key权限灾难平台刚上的时候图省事我们让所有 Agent 都共用一套服务账号去调外部系统。结果某天大模型在任务里调用了某个系统的写接口把一批测试数据改了。追查时发现根本定位不到是哪个 Agent、哪个用户触发的调用。解决方式就是“一 Agent 一身份”和“一用户一审计”。每个 Agent 在平台里有一个唯一身份标识所有对外调用都带上这个标识和上游用户 ID。系统侧能精确追踪“谁在什么时候、通过哪个 Agent、调用了什么工具、产生了什么结果”。这个机制看起来简单但企业级 AI 平台没有它审计就是空话。5.2 长上下文塞爆 Token成本雪崩第二个常见问题出现在上下文管理上。一个 Agent 跑了几轮任务之后把历史消息全部拼进 Prompt结果一次任务要消耗几万 Token。我们曾有一个 Agent 上线两周成本高得吓人一查才发现它在用户没要求的情况下把上一次的完整报告又拼进了这次调用的上下文。解决思路是两层一是“按需注入”Agent 只有在需要时才能加载指定类型的记忆二是“摘要压缩”长对话采用轮次摘要只保留关键实体和最新意图。整套上下文管理逻辑纳入平台的ContextManager组件Agent 统一走它取记忆不允许自己拼历史。5.3 工具调用的越权风险人工审批阀有些工具是非常敏感的比如“批量退款”“变更线上配置”“发对外公告”。哪怕是企业内部工具我也不建议把最终决定权完全交给模型。平台需要做“人工审批阀”当 Agent 在编排过程中检测到目标工具带requiresApproval标志时它会先暂停任务生成一个审批工单推给相关负责人。审批通过后任务继续执行审批不通过Agent 则给用户生成一条“无法执行该操作”的说明。这样做有一个很重要的附加收益它让业务部门对 AI 同事“可控”的信任度大大提高。大家不再担心 Agent 干出不可挽回的事因为真正的风险动作都有人把关。5.4 可观测性缺失看不见 Agent 在干什么如果 Agent 平台只能看结果、不能看过程排查问题就是噩梦。我们有整整一周被一个问题折磨某个 Agent 偶尔会给出错误结论但直接看结果日志看不到任何异常。后来补上了链路追踪才定位到问题出在工具调用环节大模型把参数传错了平台重试三次都是同一个错误而每次错误都被吞掉了。后来我们在平台里强制要求每次 Agent 执行都必须生产一条全链路 trace包括模型输入的 Prompt、模型输出、工具调用参数、工具返回结果、上下文注入内容。这些信息都存成结构化日志便于检索和复盘。可能有人觉得 Prompt 属于敏感信息不能存那至少存版本号和摘要不要完全缺失。5.5 并发与性能即席代码与限流最后一个容易翻车的点是并发。企业内一旦有多个团队接入平台经常出现“某个业务活动一上线Agent 调用量瞬间升高几倍”的情况。如果没有流控下游系统会先被打挂然后连锁反应导致整条链路雪崩。我们的做法是双层限流。平台网关层按 Agent 和调用方分别做 QPS 限流超过阈值直接返回“系统繁忙”执行层内部再用信号量控制并发的大模型调用数防止瞬间把模型 API 额度打完。同时把可以异步的任务都改成异步执行削峰填谷。6. 从 Demo 到全员可用上线节奏与运营小技巧6.1 四个阶段试点、打磨、推广、迭代平台上线后最尴尬的场景是“平台没人用”。所以我特别建议用阶段化的运营节奏去推进。第一阶段是试点选一个业务痛点特别强的团队帮助他们配 2-3 个 Agent。这个阶段的目标不是跑量而是跑通“平台-工具-业务-反馈”的闭环。第二阶段是打磨根据试点团队反馈优化 Prompt 模板、工具参数、审批流、知识库切片。第三阶段是推广把成型的 Agent 模板沉淀为平台上的“应用模板”让其他团队一键复制再做少量定制。第四阶段才是迭代根据使用数据持续调优淘汰低频低价值的 Agent补充高频高价值的新 Agent。6.2 模板库与 Agent 市场让“人人都能造同事”真正发生标题里说“人人都能造同事”这句话不是夸张前提是平台要有“模板资产”。我们把每一个经过验证的 Agent 抽象成可复用的模板包括岗位说明书、技能列表、权限策略、知识库挂载方式、运行参数。任何团队想建一个“合同审查助手”不用从零开始直接搜“合同审查”选一个模板改一下数据源和关键提示词就能生成自己的 Agent。这个机制让业务同学真正参与进来了。他们不写代码但他们可以提需求、“复制、粘贴、改一改”地配置同事。而研发团队只负责维护平台和模板的“工厂”本身。我曾组织过一次“Agent 创意工坊”的内部活动三天时间各部门同学自己配置了十几个可用的 AI 同事五花八门有查快递的、有算提成的、有自动回复客户邮件的。那一刻我才真正确认平台的价值不是替大家造 Agent而是让每个人都能自己造。6.3 最后分享一个关于成本控制的小技巧关于成本我的个人经验是不要等月底看账单那样太迟了。要按周看单元成本也就是每个 Agent 每次有效回答的平均 Token 消耗。我们定了一个简单的健康指标每个 Agent 的单次成本。如果连续两周上涨就去看是哪个环节烧了钱。通常元凶就三类上下文越塞越多没走摘要机制、工具返回结果太长没做字段裁剪、模型选型过重简单的“查一下”任务用了长推理模型。针对这三类问题平台里分别有对应的治理手段启用上下文压缩、给工具返回配置输出字段裁剪、调整 Agent 的modelPref属性。这些都不是一次性动作而是在运营中要持续看的指标。AI Agent 平台不是一个“上线即结束”的项目它更像一个持续运转的小型工厂你维护得越勤它给你产出的“AI 同事”就越可靠。