最近几个月我一直在推进一件事把公司里那套多年积累的研发系统逐步收敛成一个企业 Agent。说得再直白一些就是让工程师不用再同时打开 GitLab、Jenkins、Jira、K8s 控制台、监控大盘而是直接对着聊天框说一句“帮我看看 staging 环境订单服务的当前版本和最近一次发布记录”系统就能自己去找数据、做汇总、给结论再往下走一步还能在受控和审批条件下代跑流水线、建回滚单、生成测试报告。这篇文章就是我对这件事从场景到架构的一次完整复盘。如果你正在评估要不要在公司内部做 Agent或者已经在做研发侧智能体但被各种术语、框架选型和架构方案搞得眼花缭乱那这篇希望对你有用。我不会讲太飘的方向也不会硬塞概念更多是一个实际操盘者的记录场景怎么挑能力怎么拆需求怎么收敛架构怎么分层以及最后那堆坑是怎么填上的。顺便说一句真正做起来之后你会发现最难的往往不是大模型本身而是背后那套老系统、权限模型和组织流程。1. 为什么是企业 Agent从研发系统到智能体的关键跃迁1.1 研发系统的现状与核心矛盾很多公司的研发系统并不是没有能力而是能力被孤岛割开了。代码在 GitLab流水线在 Jenkins发布要在内部发布平台提工单配置在 CMDB监控在 Prometheus、Grafana线上报错在 Sentry。工程师的一天大量时间花在“查系统、翻日志、点按钮、填表单”这种低价值操作上。我们统计过一个中高级工程师平均每天花在工具切换和信息查找上的时间至少 1 到 1.5 小时团队越大损耗越明显。系统与系统之间不是没有自动化但自动化往往是点对点的脚本 Jenkins 跑完通知一下钉钉发布平台记录一下审批监控告警弹到群里。这些脚本解决的是单点问题不是一个完整的工作流程。工程师依然要自己把多条链路的信息拼起来比如查一次发布是否正常可能要先去 CI 看构建结果再去 CMDB 查集群节点再去监控平台看流量曲线最后才能得出结论。整个过程里人成了那个负责“串联”的胶水而这恰好是 Agent 最适合替代的位置。1.2 对话式助手与真正的 Agent 之间的区别很多人把“能聊天”就叫 Agent这是一个巨大的误解。聊天机器人是“你问我答”它不负责结果回答完就结束了而 Agent 的核心是“闭环执行”理解需求、拆解任务、调用工具、验证结果、向你汇报。这两者之间有一个关键的钥匙就是 LLM 的推理能力和函数调用function calling它让机器第一次能够在没有固定流程图的情况下动态决定调用哪个工具、按什么顺序调用以及如何根据中间结果调整后续动作。我常跟同事打一个比方以前我们写自动化脚本相当于定闹钟到点就响响完就完了中间没有任何判断Agent 更像一个管家你告诉他明天要早起他会自己看日程、调闹钟、帮你把早餐备好并且在需要你确认的时候跑来问你。这个“管家”背后是一整套任务规划、工具调度和结果校验的机制而不是简单的一句话回复。1.3 理解 Agent 与 Agent Harness 的边界这两年还有一个特别容易混淆的概念就是 Agent 和 Agent Harness。 OpenAI 发布 Agent SDK 时反复提 harness把不少人搞懵了。简单讲Agent 本身是那个能做推理和决策的 LLM 核心它负责“想”而 Harness 是包裹在它外面的那套运行时系统提示词、工具注册表、上下文管理、记忆、安全护栏、执行循环。没有 harnessLLM 再聪明也调不了工具、记不住上下文没有 Agentharness 也只是一堆空转的管道。在企业架构里我们要造的核心其实是 harness而不是执着于某一个特定的大模型。模型能力是供应商提供的会快速迭代但 harness 是我们能设计和掌控的地方。包括工具怎么注册、权限怎么校验、上下文怎么裁剪、任务怎么恢复这些都属于 harness 的范畴。把这个边界想明白后续的技术选型就不会被某个框架牵着鼻子走因为你知道自己真正要控制的是哪一层。2. 场景拆解先搞清楚 Agent 在研发流程里到底能做什么2.1 八个可落地的典型场景梳理做企业 Agent 最容易犯的错误是上来就想做一个“什么都懂的全能助手”。我的建议是先放弃这种想法老老实实挑场景。结合我们实际推进过程中梳理的素材研发领域至少有八个场景是当前技术条件下真正能落地、团队也确实需要的日志与监控诊断给定一个异常编号或时间点Agent 自动从日志平台、APM、监控系统中拉取数据做初步根因归纳输出“可能原因 关联证据”的摘要而不是丢一堆 raw log 让人自行分析。代码库问答与代码评审基于代码库做 RAG回答“某个方法在哪些地方被引用”“这个模块最近有没有变更”或对 MR 做自动风格检查和潜在风险提示。测试与回归执行根据需求描述自动生成测试用例触发测试流水线汇总通过率与失败堆栈并在失败时顺带拉出关联的代码提交记录。发布与部署协助查询环境当前版本协助构建发布单在审批通过后触发部署部署完成后自动检查健康检查接口和核心监控指标。工单与需求处理从一段原始需求文档中提炼用户故事、拆解任务、填充自定义字段、创建工单同时把关联的代码仓库和文档链接一并附上。知识库与文档查询把内部 Wiki、设计文档、复盘文档做成 RAG 问答让新同学可以直接问“支付链路的超时时间是怎么约定的”。数据库查询与分析在权限范围内用自然语言生成 SQL先执行 EXPLAIN 确认没有全表扫描等风险再执行只读查询敏感库强制人工确认后再放行。巡检与异常上报定时跑巡检任务生成每日研发简报发现异常自动建单并 对应负责人把重复性的“看板巡逻”自动化。这八个场景不一定每个企业都需要但方向是一致的它们都是研发流程里高频、重复、需要跨系统协作的操作。 Agent 的价值不是替代人的创造力而是把那些确定性的、可以标准化的连接动作吃掉。2.2 场景价值与复杂度评估以及切入顺序场景不能只看价值还要看落地复杂度尤其要看对生产环境的变更权限要求。我整理了一张表把上面的场景按“交互复杂度、变更权限要求、落地难度、业务价值”做了个粗略打分帮我们决定先做哪几个场景交互复杂度变更权限要求落地难度业务价值日志与监控诊断中低只读低高代码库问答与评审中低只读中中高测试与回归执行高中触发流水线中高发布与部署协助高高写操作高高工单与需求处理中中写操作影响外部系统低中知识库与文档查询低低只读低中数据库查询与分析中中读写边界要严格中高巡检与异常上报低中建单低中我们内部定过两条原则一直沿用到现在。第一条先做只读再做写操作。日志诊断、知识库问答这类场景不会破坏生产环境适合第一波落地能快速验证整套 harness 的稳定性发布、部署这种高危写操作必须放到权限体系、审计链路和审批流程全部就绪之后再说。第二条每个场景必须有一个明确的“退出按钮”用户可以在任何一步中止、撤回系统必须尊重这个信号并留痕。先把这两条体系建好再谈开放写操作。3. 能力与技术选型Agent 不是大模型而是大模型加全套管道3.1 拆开看 Agent 的核心能力把 Agent 拆开看真正的技术难点集中在六项能力意图理解、任务规划、工具调用、记忆与上下文、结果验证、安全与护栏。这六项不是各自独立的而是像流水线一样串联在一起。意图理解决定了 Agent 能不能听懂用户真正要什么任务规划决定了大目标怎么分解成小步骤工具调用是执行层能不能调得准、调得稳记忆与上下文决定了跨轮次和跨任务的信息连续性结果验证负责判断任务是不是真的完成了而不是模型“觉得”完成了安全与护栏则是贯穿始终的底线任何一步都不能脱离。这几项能力里任务规划和工具调度是最难做扎实的。规划部分常见的问题是“过度拆解”Agent 把一个本来两步就能搞定的事拆成八步中间任何一步出错整个链条就崩了。工具调用部分常见的问题是“过度自信”模型在没有真实调用结果的情况下凭训练时的记忆编造输出。所以我们在设计能力框架时明确要求“所有关键结论必须有工具返回作为支撑”宁可让 Agent 多问一次也不允许它凭空生成答案。3.2 大模型与 Agent 框架选型的取舍模型选择上企业内部尽量选 API 隔离、可审计的模型服务无论用外部 API 还是私有化部署都要保证 prompt 和内部资料不会外泄。在此基础上我建议把 embedding 模型和主 LLM 分开选小模型做路由和意图分类大模型做长链条推理和最终生成。一方面是成本控制另一方面是路由这种任务用大模型属于浪费而且延迟更高。框架这块 LangChain 这类东西做 POC 确实很爽工具集成快、上下文管理开箱即用。但真要进生产我建议把框架当成参考实现自己控制核心 harness。框架给的是轮子不是汽车真正稳定可控的是我们自己维护的那一圈代码工具注册、上下文裁剪、权限校验、执行循环。我们曾经被框架的隐性行为坑过比如它会在某些操作里自动注入额外 prompt或者在我们没有意识到的情况下改变上下文组装顺序最后排查问题时非常痛苦。拆出来自己维护之后虽然代码量多了但每一行都在自己的掌控范围内排查问题时的成本反而更低。3.3 工具层设计从内部系统 API 到 Agent 技能工具层的核心是把内部系统 API 封装成 Agent 能理解和调用的函数。这里有两个特别容易被忽视的细节。第一函数描述的质量比函数本身更重要。LLM 不是靠类型推断来决定调用哪个工具的而是靠描述description 写得太笼统它就会在相似工具之间乱调描述写得太复杂又容易让模型产生错误理解。我们的经验是描述里明确写出这个工具“在什么场景下用、输入是什么、输出会返回什么、有没有权限限制”必要的时候给出一个 few-shot 示例。第二所有工具都必须有超时和重试机制并且要尽量幂等。 Agent 在执行多步任务时经常出现一个工具超时导致整个推理链崩溃的情况。所以我们给每个工具设了独立 timeout比如 Git 查询 10 秒流水线触发 30 秒并在工具层做指数退避重试。更保险的做法是把耗时长的操作改成异步任务工具只负责提交任务并返回 task IDAgent 再通过轮询接口去查询执行结果。这样即使底层系统处理很慢也不会把 Agent 的执行循环卡死。3.4 记忆、技能与多 Agent 协作记忆设计方面我习惯分成三层。短期记忆是当前对话的上下文要注意 token 预算及时做摘要压缩长期记忆用向量库存知识、项目背景、历史决定通过 embedding 做相似检索工作记忆则是单次任务内部的状态比如“已经执行到第几步、哪些操作被批准了”这通常放在 Redis 或任务实例里。企业场景里尤其要注意工程上下文用户是谁、在哪个项目、面对的是哪个环境这些信息要提前注入能大幅减少模型的误解。关于“技能”和 Agent 的区别这也是一直有人问的点。简单讲技能是原子能力类似乐高积木里的单独一块 Agent 是那个能决定怎么拼积木的人。技能往往是“一个输入、一个输出”的确定函数而 Agent 会根据情况动态决定用哪些技能、以什么顺序用。我们内部的做法是把工具层设计成“技能库”每个技能对应一个或多个工具Agent 通过工具调度器去引用技能而不是直接操作底层 API。这样既能复用技能又能隔离权限。至于多 Agent 协作我的建议是能不用就先不用。多数场景下一个规划器加一个工具调度器就够了。多个 Agent 的 Supervisor/Worker 模式通信协议和状态同步复杂度会直线上升很多时候并不是问题的最优解。只有当你真的需要角色隔离比如“做代码评审的 Agent”和“做部署的 Agent”权限完全不同才值得拆成独立 Agent。在那之前用工具权限标签区分职责比拆多个 Agent 要简单得多。4. 需求梳理与总体架构从编排层到安全护栏的落地设计4.1 功能性需求梳理要点需求这块不要只写“支持智能问答”每一条都要能验收。我们当时把所有需求整理成三类。用户侧需求支持自然语言交互、权限范围内的操作、操作可追溯、关键步骤可确认系统侧需求外部系统只能通过工具层对接、会话和操作数据落库、监控告警完善管理侧需求管理员可以配置工具权限、动态调整模型参数、查看审计日志、维护知识库和技能库。需求梳理过程中最容易吵起来的是“操作边界”。研发同学希望 Agent 能直接改配置、发版本安全团队坚持所有变更必须走审批。最后我们达成的共识是变更类操作一律拆成“申请”和“执行”两步 Agent 负责发起申请和准备执行所需的信息审批通过后再由 Agent 自动执行但执行结果必须做健康检查。这套流程虽然比人直接操作多了道手续但每一步都可追溯、可回滚反而让团队对 Agent 的信任度大幅提升。4.2 非功能性需求与约束非功能需求里响应时延、可靠性、安全合规、可观测性四件事优先级最高。读操作建议 P95 在 3 秒内写操作因为要走审批链路可以放宽到 30 秒内。可靠性要设计重试和降级大模型服务不可用时系统应该提示降级到基础命令模式而不是直接把一堆英文报错甩给用户。安全合规上所有 Agent 调用的工具都要过权限网关外部系统产生的凭证不能暴露给模型日志要做脱敏。可观测性要记录每个任务的完整 trace从用户 query 到每一步工具调用的输入输出没有 trace 就无法 debug这一点几乎是所有 Agent 生产环境事故复盘的第一条教训。4.3 总体架构分层设计总体架构我习惯分成六层每一层的边界尽量清晰。最外层是接入层支持 Web、IM企业微信、钉钉、飞书等入口统一走 SSO保证进来的人身份是确定的。往下是交互与对话层负责会话管理、意图识别、权限前置校验。再往中间是 Agent 编排层这是核心包含规划器、工具调度器、上下文管理器、记忆管理器、护栏策略。再下面是工具集成层把 GitLab、Jenkins、K8s、CMDB 等系统封装成标准工具每个工具都有输入输出 schema 和权限标签。再往下是数据层存会话记录、向量库、审计日志、评估集。最底层是基础设施K8s、消息队列、监控系统。一次典型请求的路径是这样的用户在 IM 里发起 query接入层完成身份认证权限前置校验先确认用户有没有调用相关工具的权限编排层把 query 送入规划器规划器决定用哪些工具工具调度器逐个调用每个调用都经过权限网关得到结果后放回上下文如果涉及生产变更会触发审批节点等待对应负责人确认后继续执行最终结果汇总后通过 IM 回给用户。整条链路从 query 到 tool 调用再到审批动作全部写进审计日志。4.4 安全与护栏设计是重头戏安全设计上的一个核心原则是模型本身不可信所有外部输入都要当数据看不能当指令看。具体到实现我建议至少做四件事。第一所有工具调用必须经过权限中间件校验用户身份、角色、资源标签三者匹配。第二外部文档内容比如网页、代码注释、用户反馈在进入上下文之前要做隔离和标记防止提示词注入。第三对 Agent 输出要做二次校验比如生成的 SQL 先跑 EXPLAIN发布命令先走 dry-run避免幻觉带来的误操作。第四自然语言操作要有高危词表“删除”“停止”“回滚”这类动词必须强制二次确认。安全问题没法靠一段代码解决它是一个体系。我也见过团队把大量精力花在让模型更聪明上却忽略了权限网关和审计日志结果一上线就出了越权操作的事故。企业 Agent 一旦要对接真实生产系统安全护栏的优先级永远高于模型能力。下面这张表是我内部经常用来做自查的风险点可能后果缓解措施工具越权调用普通用户执行了管理员操作权限中间件统一拦截角色与资源标签双匹配提示词注入外部文本诱导 Agent 执行恶意指令外部数据标记隔离不拼接进规划器提示词模型幻觉编造工具结果或发布成功关键结论强制要求工具返回作为依据凭证泄露高危系统凭证被模型读出凭证只存在工具层不进入上下文高危操作误触发删除资源、回滚版本高危词表强制二次确认 审批流5. 落地实操从零到一的路线图与问题排查5.1 分阶段落地路线图落地路径我建议分成五个阶段不要跳步。阶段一POC 验证挑一个只读场景比如知识库问答或日志诊断用现成框架接一个系统跑通端到端验证模型能力和工具调用的基本可行性。阶段二Harness 建设把工具注册、权限校验、会话管理抽成独立服务逐步摆脱对框架内部逻辑的依赖。阶段三评估体系沉淀 golden set 和自动化评估脚本每次改动模型或工具描述后都跑一遍回归。阶段四业务扩展再接入两到三个系统开放只读场景给种子用户收集真实使用数据和反馈。阶段五加固推广正式开放写操作接审计、审批、监控告警然后做大规模推广。这个路线图的核心思路是先窄后宽、先读后写、先内部后全员。我见过不少团队一上来就把目标定成全场景全能 Agent结果半年过去了还停留在演示 Demo。反倒是我们从日志诊断这个窄场景切入三个月内就有了一批真实用户后面推广新场景时阻力小很多。5.2 我踩过的坑与排查方法做企业 Agent 的过程中踩坑是必然的。下面这些是我遇到过的典型问题以及对应的解决思路症状可能原因排查与解决方案工具调用错乱需要查 Git 却调了 CI工具描述模糊模型搞不清边界优化工具 description增加 few-shot 示例强制输出 schema 校验任务卡死或长时间无响应工具没有超时控制长任务被同步阻塞每个工具设置独立 timeout长任务转异步轮询回答与事实不符缺少结果验证环节模型凭记忆生成强制在关键步骤后查证工具返回状态校验不通过就重试上下文越堆越长最终爆掉工具返回结果太大没有做裁剪工具返回只保留摘要和关键字段长对话时空上下文做压缩权限绕过或提示词注入外部内容被当成指令拼接进 planner外部数据统一标记为不可信与系统提示词隔离存储模型对同一问题表现不稳定环境变量、工具列表、上下文顺序变动把工具列表和上下文组装逻辑固定成模板变更走评审最让我印象深刻的坑是工具返回结果太大导致上下文爆炸。一开始我们把 Git 提交记录的完整 diff 都塞给模型结果跑两轮就把 token 用完了后面的任务全部失败。后来改成只传提交摘要、变更文件列表和关键行的 diff模型的表现反而更好了因为噪音少了。这让我意识到工具层不是把所有信息都交给模型而是要帮模型做一次信息过滤和整理。5.3 给 Agent 做评估体系评估这块很多人会忽略但它才是 Agent 能不能长期演进的命根子。Agent 的评估不能只看最终答案对不对还要看流程合不合理。我们建了一套三层评估任务成功率最终结果是否满足要求过程规范性工具调用顺序是否合理、有没有多余或越权动作用户体验响应时间、是否需要人工干预、用户反馈打分。每次迭代模型、工具描述、系统提示词都必须跑一遍回归集不然很容易出现“这次修好了 A 场景结果 B 场景又坏了”的问题。我们的 golden set 是从真实用户会话里筛出来的包含了正常场景、边界场景和恶意输入三类样本。自动化评估脚本会把每次实验的结果对比出来低于阈值就阻止上线。这套体系虽然初期建设成本不低但它保证了 Agent 在持续迭代中不会越改越乱。最后说点个人感受。做企业 Agent 最耗费精力的不是写推理逻辑而是连接系统和设计控制点。你必须熟悉自家 CICD 平台的每一个枚举值必须跟安全团队一个个过权限矩阵必须接受“即使 Agent 再聪明审批流还是要保留”这个事实。根据我的经验最稳妥的切入方式是从一个特别具体的、每天都会遇到的痛点场景开始把它做透让团队真正用到、离不开再慢慢长成平台。至于 Agent 是不是未来我觉得是但通往未来的路不在 Chatbot 的花哨话术而在那一层我们可控的 harness 里。
企业Agent落地实践：从研发系统到智能体的架构设计与踩坑复盘
最近几个月我一直在推进一件事把公司里那套多年积累的研发系统逐步收敛成一个企业 Agent。说得再直白一些就是让工程师不用再同时打开 GitLab、Jenkins、Jira、K8s 控制台、监控大盘而是直接对着聊天框说一句“帮我看看 staging 环境订单服务的当前版本和最近一次发布记录”系统就能自己去找数据、做汇总、给结论再往下走一步还能在受控和审批条件下代跑流水线、建回滚单、生成测试报告。这篇文章就是我对这件事从场景到架构的一次完整复盘。如果你正在评估要不要在公司内部做 Agent或者已经在做研发侧智能体但被各种术语、框架选型和架构方案搞得眼花缭乱那这篇希望对你有用。我不会讲太飘的方向也不会硬塞概念更多是一个实际操盘者的记录场景怎么挑能力怎么拆需求怎么收敛架构怎么分层以及最后那堆坑是怎么填上的。顺便说一句真正做起来之后你会发现最难的往往不是大模型本身而是背后那套老系统、权限模型和组织流程。1. 为什么是企业 Agent从研发系统到智能体的关键跃迁1.1 研发系统的现状与核心矛盾很多公司的研发系统并不是没有能力而是能力被孤岛割开了。代码在 GitLab流水线在 Jenkins发布要在内部发布平台提工单配置在 CMDB监控在 Prometheus、Grafana线上报错在 Sentry。工程师的一天大量时间花在“查系统、翻日志、点按钮、填表单”这种低价值操作上。我们统计过一个中高级工程师平均每天花在工具切换和信息查找上的时间至少 1 到 1.5 小时团队越大损耗越明显。系统与系统之间不是没有自动化但自动化往往是点对点的脚本 Jenkins 跑完通知一下钉钉发布平台记录一下审批监控告警弹到群里。这些脚本解决的是单点问题不是一个完整的工作流程。工程师依然要自己把多条链路的信息拼起来比如查一次发布是否正常可能要先去 CI 看构建结果再去 CMDB 查集群节点再去监控平台看流量曲线最后才能得出结论。整个过程里人成了那个负责“串联”的胶水而这恰好是 Agent 最适合替代的位置。1.2 对话式助手与真正的 Agent 之间的区别很多人把“能聊天”就叫 Agent这是一个巨大的误解。聊天机器人是“你问我答”它不负责结果回答完就结束了而 Agent 的核心是“闭环执行”理解需求、拆解任务、调用工具、验证结果、向你汇报。这两者之间有一个关键的钥匙就是 LLM 的推理能力和函数调用function calling它让机器第一次能够在没有固定流程图的情况下动态决定调用哪个工具、按什么顺序调用以及如何根据中间结果调整后续动作。我常跟同事打一个比方以前我们写自动化脚本相当于定闹钟到点就响响完就完了中间没有任何判断Agent 更像一个管家你告诉他明天要早起他会自己看日程、调闹钟、帮你把早餐备好并且在需要你确认的时候跑来问你。这个“管家”背后是一整套任务规划、工具调度和结果校验的机制而不是简单的一句话回复。1.3 理解 Agent 与 Agent Harness 的边界这两年还有一个特别容易混淆的概念就是 Agent 和 Agent Harness。 OpenAI 发布 Agent SDK 时反复提 harness把不少人搞懵了。简单讲Agent 本身是那个能做推理和决策的 LLM 核心它负责“想”而 Harness 是包裹在它外面的那套运行时系统提示词、工具注册表、上下文管理、记忆、安全护栏、执行循环。没有 harnessLLM 再聪明也调不了工具、记不住上下文没有 Agentharness 也只是一堆空转的管道。在企业架构里我们要造的核心其实是 harness而不是执着于某一个特定的大模型。模型能力是供应商提供的会快速迭代但 harness 是我们能设计和掌控的地方。包括工具怎么注册、权限怎么校验、上下文怎么裁剪、任务怎么恢复这些都属于 harness 的范畴。把这个边界想明白后续的技术选型就不会被某个框架牵着鼻子走因为你知道自己真正要控制的是哪一层。2. 场景拆解先搞清楚 Agent 在研发流程里到底能做什么2.1 八个可落地的典型场景梳理做企业 Agent 最容易犯的错误是上来就想做一个“什么都懂的全能助手”。我的建议是先放弃这种想法老老实实挑场景。结合我们实际推进过程中梳理的素材研发领域至少有八个场景是当前技术条件下真正能落地、团队也确实需要的日志与监控诊断给定一个异常编号或时间点Agent 自动从日志平台、APM、监控系统中拉取数据做初步根因归纳输出“可能原因 关联证据”的摘要而不是丢一堆 raw log 让人自行分析。代码库问答与代码评审基于代码库做 RAG回答“某个方法在哪些地方被引用”“这个模块最近有没有变更”或对 MR 做自动风格检查和潜在风险提示。测试与回归执行根据需求描述自动生成测试用例触发测试流水线汇总通过率与失败堆栈并在失败时顺带拉出关联的代码提交记录。发布与部署协助查询环境当前版本协助构建发布单在审批通过后触发部署部署完成后自动检查健康检查接口和核心监控指标。工单与需求处理从一段原始需求文档中提炼用户故事、拆解任务、填充自定义字段、创建工单同时把关联的代码仓库和文档链接一并附上。知识库与文档查询把内部 Wiki、设计文档、复盘文档做成 RAG 问答让新同学可以直接问“支付链路的超时时间是怎么约定的”。数据库查询与分析在权限范围内用自然语言生成 SQL先执行 EXPLAIN 确认没有全表扫描等风险再执行只读查询敏感库强制人工确认后再放行。巡检与异常上报定时跑巡检任务生成每日研发简报发现异常自动建单并 对应负责人把重复性的“看板巡逻”自动化。这八个场景不一定每个企业都需要但方向是一致的它们都是研发流程里高频、重复、需要跨系统协作的操作。 Agent 的价值不是替代人的创造力而是把那些确定性的、可以标准化的连接动作吃掉。2.2 场景价值与复杂度评估以及切入顺序场景不能只看价值还要看落地复杂度尤其要看对生产环境的变更权限要求。我整理了一张表把上面的场景按“交互复杂度、变更权限要求、落地难度、业务价值”做了个粗略打分帮我们决定先做哪几个场景交互复杂度变更权限要求落地难度业务价值日志与监控诊断中低只读低高代码库问答与评审中低只读中中高测试与回归执行高中触发流水线中高发布与部署协助高高写操作高高工单与需求处理中中写操作影响外部系统低中知识库与文档查询低低只读低中数据库查询与分析中中读写边界要严格中高巡检与异常上报低中建单低中我们内部定过两条原则一直沿用到现在。第一条先做只读再做写操作。日志诊断、知识库问答这类场景不会破坏生产环境适合第一波落地能快速验证整套 harness 的稳定性发布、部署这种高危写操作必须放到权限体系、审计链路和审批流程全部就绪之后再说。第二条每个场景必须有一个明确的“退出按钮”用户可以在任何一步中止、撤回系统必须尊重这个信号并留痕。先把这两条体系建好再谈开放写操作。3. 能力与技术选型Agent 不是大模型而是大模型加全套管道3.1 拆开看 Agent 的核心能力把 Agent 拆开看真正的技术难点集中在六项能力意图理解、任务规划、工具调用、记忆与上下文、结果验证、安全与护栏。这六项不是各自独立的而是像流水线一样串联在一起。意图理解决定了 Agent 能不能听懂用户真正要什么任务规划决定了大目标怎么分解成小步骤工具调用是执行层能不能调得准、调得稳记忆与上下文决定了跨轮次和跨任务的信息连续性结果验证负责判断任务是不是真的完成了而不是模型“觉得”完成了安全与护栏则是贯穿始终的底线任何一步都不能脱离。这几项能力里任务规划和工具调度是最难做扎实的。规划部分常见的问题是“过度拆解”Agent 把一个本来两步就能搞定的事拆成八步中间任何一步出错整个链条就崩了。工具调用部分常见的问题是“过度自信”模型在没有真实调用结果的情况下凭训练时的记忆编造输出。所以我们在设计能力框架时明确要求“所有关键结论必须有工具返回作为支撑”宁可让 Agent 多问一次也不允许它凭空生成答案。3.2 大模型与 Agent 框架选型的取舍模型选择上企业内部尽量选 API 隔离、可审计的模型服务无论用外部 API 还是私有化部署都要保证 prompt 和内部资料不会外泄。在此基础上我建议把 embedding 模型和主 LLM 分开选小模型做路由和意图分类大模型做长链条推理和最终生成。一方面是成本控制另一方面是路由这种任务用大模型属于浪费而且延迟更高。框架这块 LangChain 这类东西做 POC 确实很爽工具集成快、上下文管理开箱即用。但真要进生产我建议把框架当成参考实现自己控制核心 harness。框架给的是轮子不是汽车真正稳定可控的是我们自己维护的那一圈代码工具注册、上下文裁剪、权限校验、执行循环。我们曾经被框架的隐性行为坑过比如它会在某些操作里自动注入额外 prompt或者在我们没有意识到的情况下改变上下文组装顺序最后排查问题时非常痛苦。拆出来自己维护之后虽然代码量多了但每一行都在自己的掌控范围内排查问题时的成本反而更低。3.3 工具层设计从内部系统 API 到 Agent 技能工具层的核心是把内部系统 API 封装成 Agent 能理解和调用的函数。这里有两个特别容易被忽视的细节。第一函数描述的质量比函数本身更重要。LLM 不是靠类型推断来决定调用哪个工具的而是靠描述description 写得太笼统它就会在相似工具之间乱调描述写得太复杂又容易让模型产生错误理解。我们的经验是描述里明确写出这个工具“在什么场景下用、输入是什么、输出会返回什么、有没有权限限制”必要的时候给出一个 few-shot 示例。第二所有工具都必须有超时和重试机制并且要尽量幂等。 Agent 在执行多步任务时经常出现一个工具超时导致整个推理链崩溃的情况。所以我们给每个工具设了独立 timeout比如 Git 查询 10 秒流水线触发 30 秒并在工具层做指数退避重试。更保险的做法是把耗时长的操作改成异步任务工具只负责提交任务并返回 task IDAgent 再通过轮询接口去查询执行结果。这样即使底层系统处理很慢也不会把 Agent 的执行循环卡死。3.4 记忆、技能与多 Agent 协作记忆设计方面我习惯分成三层。短期记忆是当前对话的上下文要注意 token 预算及时做摘要压缩长期记忆用向量库存知识、项目背景、历史决定通过 embedding 做相似检索工作记忆则是单次任务内部的状态比如“已经执行到第几步、哪些操作被批准了”这通常放在 Redis 或任务实例里。企业场景里尤其要注意工程上下文用户是谁、在哪个项目、面对的是哪个环境这些信息要提前注入能大幅减少模型的误解。关于“技能”和 Agent 的区别这也是一直有人问的点。简单讲技能是原子能力类似乐高积木里的单独一块 Agent 是那个能决定怎么拼积木的人。技能往往是“一个输入、一个输出”的确定函数而 Agent 会根据情况动态决定用哪些技能、以什么顺序用。我们内部的做法是把工具层设计成“技能库”每个技能对应一个或多个工具Agent 通过工具调度器去引用技能而不是直接操作底层 API。这样既能复用技能又能隔离权限。至于多 Agent 协作我的建议是能不用就先不用。多数场景下一个规划器加一个工具调度器就够了。多个 Agent 的 Supervisor/Worker 模式通信协议和状态同步复杂度会直线上升很多时候并不是问题的最优解。只有当你真的需要角色隔离比如“做代码评审的 Agent”和“做部署的 Agent”权限完全不同才值得拆成独立 Agent。在那之前用工具权限标签区分职责比拆多个 Agent 要简单得多。4. 需求梳理与总体架构从编排层到安全护栏的落地设计4.1 功能性需求梳理要点需求这块不要只写“支持智能问答”每一条都要能验收。我们当时把所有需求整理成三类。用户侧需求支持自然语言交互、权限范围内的操作、操作可追溯、关键步骤可确认系统侧需求外部系统只能通过工具层对接、会话和操作数据落库、监控告警完善管理侧需求管理员可以配置工具权限、动态调整模型参数、查看审计日志、维护知识库和技能库。需求梳理过程中最容易吵起来的是“操作边界”。研发同学希望 Agent 能直接改配置、发版本安全团队坚持所有变更必须走审批。最后我们达成的共识是变更类操作一律拆成“申请”和“执行”两步 Agent 负责发起申请和准备执行所需的信息审批通过后再由 Agent 自动执行但执行结果必须做健康检查。这套流程虽然比人直接操作多了道手续但每一步都可追溯、可回滚反而让团队对 Agent 的信任度大幅提升。4.2 非功能性需求与约束非功能需求里响应时延、可靠性、安全合规、可观测性四件事优先级最高。读操作建议 P95 在 3 秒内写操作因为要走审批链路可以放宽到 30 秒内。可靠性要设计重试和降级大模型服务不可用时系统应该提示降级到基础命令模式而不是直接把一堆英文报错甩给用户。安全合规上所有 Agent 调用的工具都要过权限网关外部系统产生的凭证不能暴露给模型日志要做脱敏。可观测性要记录每个任务的完整 trace从用户 query 到每一步工具调用的输入输出没有 trace 就无法 debug这一点几乎是所有 Agent 生产环境事故复盘的第一条教训。4.3 总体架构分层设计总体架构我习惯分成六层每一层的边界尽量清晰。最外层是接入层支持 Web、IM企业微信、钉钉、飞书等入口统一走 SSO保证进来的人身份是确定的。往下是交互与对话层负责会话管理、意图识别、权限前置校验。再往中间是 Agent 编排层这是核心包含规划器、工具调度器、上下文管理器、记忆管理器、护栏策略。再下面是工具集成层把 GitLab、Jenkins、K8s、CMDB 等系统封装成标准工具每个工具都有输入输出 schema 和权限标签。再往下是数据层存会话记录、向量库、审计日志、评估集。最底层是基础设施K8s、消息队列、监控系统。一次典型请求的路径是这样的用户在 IM 里发起 query接入层完成身份认证权限前置校验先确认用户有没有调用相关工具的权限编排层把 query 送入规划器规划器决定用哪些工具工具调度器逐个调用每个调用都经过权限网关得到结果后放回上下文如果涉及生产变更会触发审批节点等待对应负责人确认后继续执行最终结果汇总后通过 IM 回给用户。整条链路从 query 到 tool 调用再到审批动作全部写进审计日志。4.4 安全与护栏设计是重头戏安全设计上的一个核心原则是模型本身不可信所有外部输入都要当数据看不能当指令看。具体到实现我建议至少做四件事。第一所有工具调用必须经过权限中间件校验用户身份、角色、资源标签三者匹配。第二外部文档内容比如网页、代码注释、用户反馈在进入上下文之前要做隔离和标记防止提示词注入。第三对 Agent 输出要做二次校验比如生成的 SQL 先跑 EXPLAIN发布命令先走 dry-run避免幻觉带来的误操作。第四自然语言操作要有高危词表“删除”“停止”“回滚”这类动词必须强制二次确认。安全问题没法靠一段代码解决它是一个体系。我也见过团队把大量精力花在让模型更聪明上却忽略了权限网关和审计日志结果一上线就出了越权操作的事故。企业 Agent 一旦要对接真实生产系统安全护栏的优先级永远高于模型能力。下面这张表是我内部经常用来做自查的风险点可能后果缓解措施工具越权调用普通用户执行了管理员操作权限中间件统一拦截角色与资源标签双匹配提示词注入外部文本诱导 Agent 执行恶意指令外部数据标记隔离不拼接进规划器提示词模型幻觉编造工具结果或发布成功关键结论强制要求工具返回作为依据凭证泄露高危系统凭证被模型读出凭证只存在工具层不进入上下文高危操作误触发删除资源、回滚版本高危词表强制二次确认 审批流5. 落地实操从零到一的路线图与问题排查5.1 分阶段落地路线图落地路径我建议分成五个阶段不要跳步。阶段一POC 验证挑一个只读场景比如知识库问答或日志诊断用现成框架接一个系统跑通端到端验证模型能力和工具调用的基本可行性。阶段二Harness 建设把工具注册、权限校验、会话管理抽成独立服务逐步摆脱对框架内部逻辑的依赖。阶段三评估体系沉淀 golden set 和自动化评估脚本每次改动模型或工具描述后都跑一遍回归。阶段四业务扩展再接入两到三个系统开放只读场景给种子用户收集真实使用数据和反馈。阶段五加固推广正式开放写操作接审计、审批、监控告警然后做大规模推广。这个路线图的核心思路是先窄后宽、先读后写、先内部后全员。我见过不少团队一上来就把目标定成全场景全能 Agent结果半年过去了还停留在演示 Demo。反倒是我们从日志诊断这个窄场景切入三个月内就有了一批真实用户后面推广新场景时阻力小很多。5.2 我踩过的坑与排查方法做企业 Agent 的过程中踩坑是必然的。下面这些是我遇到过的典型问题以及对应的解决思路症状可能原因排查与解决方案工具调用错乱需要查 Git 却调了 CI工具描述模糊模型搞不清边界优化工具 description增加 few-shot 示例强制输出 schema 校验任务卡死或长时间无响应工具没有超时控制长任务被同步阻塞每个工具设置独立 timeout长任务转异步轮询回答与事实不符缺少结果验证环节模型凭记忆生成强制在关键步骤后查证工具返回状态校验不通过就重试上下文越堆越长最终爆掉工具返回结果太大没有做裁剪工具返回只保留摘要和关键字段长对话时空上下文做压缩权限绕过或提示词注入外部内容被当成指令拼接进 planner外部数据统一标记为不可信与系统提示词隔离存储模型对同一问题表现不稳定环境变量、工具列表、上下文顺序变动把工具列表和上下文组装逻辑固定成模板变更走评审最让我印象深刻的坑是工具返回结果太大导致上下文爆炸。一开始我们把 Git 提交记录的完整 diff 都塞给模型结果跑两轮就把 token 用完了后面的任务全部失败。后来改成只传提交摘要、变更文件列表和关键行的 diff模型的表现反而更好了因为噪音少了。这让我意识到工具层不是把所有信息都交给模型而是要帮模型做一次信息过滤和整理。5.3 给 Agent 做评估体系评估这块很多人会忽略但它才是 Agent 能不能长期演进的命根子。Agent 的评估不能只看最终答案对不对还要看流程合不合理。我们建了一套三层评估任务成功率最终结果是否满足要求过程规范性工具调用顺序是否合理、有没有多余或越权动作用户体验响应时间、是否需要人工干预、用户反馈打分。每次迭代模型、工具描述、系统提示词都必须跑一遍回归集不然很容易出现“这次修好了 A 场景结果 B 场景又坏了”的问题。我们的 golden set 是从真实用户会话里筛出来的包含了正常场景、边界场景和恶意输入三类样本。自动化评估脚本会把每次实验的结果对比出来低于阈值就阻止上线。这套体系虽然初期建设成本不低但它保证了 Agent 在持续迭代中不会越改越乱。最后说点个人感受。做企业 Agent 最耗费精力的不是写推理逻辑而是连接系统和设计控制点。你必须熟悉自家 CICD 平台的每一个枚举值必须跟安全团队一个个过权限矩阵必须接受“即使 Agent 再聪明审批流还是要保留”这个事实。根据我的经验最稳妥的切入方式是从一个特别具体的、每天都会遇到的痛点场景开始把它做透让团队真正用到、离不开再慢慢长成平台。至于 Agent 是不是未来我觉得是但通往未来的路不在 Chatbot 的花哨话术而在那一层我们可控的 harness 里。