本文分享了某团队将大模型能力接入机器学习平台运维场景的4个月实践。核心观点包括：应避免过早将简单问题复杂化，Agent并非万能，而是由业务问题驱动逐步演进；区分Workflow与Agent的关键在于LLM是否参与动态决策；推荐"Workflow包Agent"的架构模式，外层保持确定性，内层处理不确定性；强调工程能力的重要性，包括Guardrails设计、可观测性、工具质量、Prompt分层等；未来将聚焦Eval自动化和多Agent状态协议建设。实践证明，好的Agent工程是在约束与放大间找到平衡，先解决确定性流程问题，再为关键环节赋予受控的智能判断能力。

---

很多 Agent 项目失败，不是模型不够强，而是团队太早把简单问题做复杂了。

过去 4 个多月，我们一直在做一件事：把大模型能力接入机器学习平台的运维场景。

最开始，它只是一个 AI 助手：回答问题、查知识库、帮值班同学总结任务和告警信息。后来，它开始接入更多上下文：任务状态、日志、指标、告警工单、历史处理经验。再后来，我们把一些固定排查流程做成 Workflow，让系统自动完成“查数据 -> 整理上下文 -> 调用模型 -> 输出结论 -> 通知值班人”这一整套动作。

直到某些复杂告警场景里，固定流程真的覆盖不了了，我们才开始引入 Agent。

这个过程回头看很有意思：我们并不是先设计了一个“Agentic Platform”，再往里填功能；恰恰相反，是业务问题一步步把系统推到了 Agent。

Anthropic 在《Building effective agents》里有一句话，我现在非常认同：

You should consider adding complexity only when it demonstrably improves outcomes.

只有当复杂度能带来可证明的效果提升时，才值得引入更复杂的 Agent 架构。这篇文章不是概念科普，而是一次实践复盘：我们为什么没有一开始就做 Agent，什么时候才真正需要 Agent，以及一个 Agent 要进入生产环境，背后到底需要哪些工程能力。

---

1. 用了大模型，不等于做了 Agent
   ====================

过去几个月，很多讨论都会回到同一个问题：一个平台里有 LLM、有 RAG、有工具调用、有自动化流程，它到底算不算 Agent？

我的答案是：不一定。Anthropic 把 agentic systems 分成两类：Workflow是 LLM 和工具按照开发者预先定义好的代码路径执行；Agent是 LLM 动态决定自己的执行过程和工具使用方式。说得更直白一点，就是看谁在开车。

如果流程怎么走、工具什么时候调、什么时候停止，都是代码提前写好的，LLM 只是其中一个节点，用来摘要、分类、抽取或生成建议，那么它是 Workflow。如果 LLM 会根据当前观察结果决定下一步做什么、调用哪个工具、是否继续追查、何时停止，它才开始具备 Agent 的特征。

我们后来内部用一个很简单的判断表：

问题	Workflow	Agent
LLM 在流程里做什么？	填空、总结、判断局部问题	决定下一步行动
控制流由谁决定？	代码提前定义	模型根据中间结果动态决定
工具调用次数是否固定？	通常固定或半固定	取决于模型判断
停止条件是什么？	流程跑完或规则命中	模型判断证据是否足够，同时受工程上限约束

一个真正的 Agent，至少需要三件事：LLM 参与决策，能调用工具，能循环推进任务。缺一个，都不要轻易叫 Agent。

这不是抠字眼。定义错了，架构就会选错。很多场景用 Workflow 就能稳定解决，强行做成 Agent，只会增加成本、延迟和不可控性。

---

2. 我们不是跳到 Agent，而是被问题推过去的
   =========================

如果把这 4 个多月压缩成一条线，大概是：

AI 问答 -> RAG 知识库 -> 工具调用 -> 多节点 Workflow -> 局部 Agent -> Agentic Platform

第一阶段解决“知道什么”。平台里有很多任务、指标、规则、排查经验，值班同学需要快速问到答案，RAG 和单次 LLM 调用就很有价值。

第二阶段解决“能查什么”。只靠知识库不够，很多问题必须查实时状态：任务是否卡住、日志有没有异常、指标有没有抖动、告警上下文是什么。于是我们把工具接进来。

第三阶段解决“能自动做什么”。一些告警处理流程高度固定：先查工单，再查日志，再整理上下文，再让 LLM 分析，再通知值班人。这类场景不需要 Agent，用 Workflow 更合适。

第四阶段才是真正的 Agent 问题。有些复杂告警不是固定流程能覆盖的：同一个告警标题背后可能是多种根因；第一轮日志可能看不出结论；有时要查上游，有时要查下游，有时要看指标，有时要结合历史 SOP；证据不够时，还要继续追一轮。

这时候，继续把路径写死，流程图会迅速膨胀。Agent 不是因为“技术上很酷”才出现，而是因为固定流程的边界到了。

所以我现在判断一个团队是否该做 Agent，标准不是“会不会 ReAct”，而是：有没有足够多的失败样本，证明固定路径已经不够了。

---

3. 最稳的模式：Workflow 包 Agent
   =========================

我们最终采用的模式，可以概括为一句话：

外层用 Workflow 保持确定性，内层用 Agent 处理不确定性。

一个典型流程长这样：

触发 -> 分诊 -> Agent 调查 -> 结构化提取 -> 质量评估 -> 汇总输出 -> 通知 / 人工处理

这里面，真正的 Agent 只在“调查”这一段。触发、分诊、结构化、评估、通知，尽量保持确定性。

这么设计有四个原因。第一，不是所有请求都值得进入 Agent，有些告警没有实际异常，有些通过基础指标就能短路，前置分诊能省 token，也能降低误判。第二，Agent 必须有边界：模型可以决定查什么，但不能无限查；可以提出建议，但不能绕过审批；可以给出判断，但必须附带证据和置信度。第三，输出必须能被系统消费，如果只是一段自然语言，后续很难统计、复盘、回归和产品化展示。第四，评估节点要独立，调查节点负责找证据，评估节点负责判断证据够不够，证据不足就回到调查，证据足够再输出。

这套架构的好处是：Agent 有足够的自由，但自由被装在一个可控容器里。

生产系统里最可靠的 Agent，不是全 Agent，而是被 Workflow 包起来的 Agent。

---

4. Workflow 不是低级形态，而是 Agent 的工程底座
   =================================

Anthropic 总结了五种常见 Workflow 模式。回看我们的实践，几乎都踩了一遍，但它们不是“Agent 之前的低级阶段”，而是 Agent 能进生产的工程底座。

Prompt Chaining适合把复杂任务拆成小任务。早期日志分析、慢任务分析，本质都是链式流程：先查数据，再整理，再让 LLM 分析，再输出结论。它不酷，但稳定。

Routing解决的是“不要用一个 Prompt 处理所有问题”。告警类型越来越多后，一个万能 Prompt 很快失效。不同服务、地区、任务类型、严重程度，需要不同的上下文、工具和排查策略。

Parallelization的价值是先把上下文并行拿齐。很多诊断任务第一步不是推理，而是收集信息：日志、指标、任务状态、上下游链路、变更事件。并行化不是炫技，而是让 Agent 一开始就站在更完整的上下文上。

Orchestrator-Workers适合把专业能力封装出去。当问题涉及下游链路，不应该让主流程写死所有服务路径，而应该把拓扑分析、下游排查、日志归因这些能力封装成专门子能力，由主 Agent 决定是否调用。

Evaluator-Optimizer是我们后来非常重视的一点。Agent 给出结论后，不应该马上结束，而应该有独立评估环节检查：证据是否足够、置信度是否达标、有没有遗漏关键指标、需不需要再查一轮。这让 Agent 从“一次性回答问题”，变成“迭代逼近答案”。

---

5. 生产 Agent，最容易低估的是工程托底
   =======================

Demo 阶段，大家关注模型聪不聪明；生产阶段，真正决定系统能不能跑起来的，往往是工程托底。

第一，Guardrails 不是 Prompt 补丁。在系统提示词里多写几句“不要幻觉”“必须谨慎”远远不够。Guardrails 至少包括四类边界：事实边界，事实和推断必须分开，结论必须能追溯到证据；行动边界，高风险动作必须有人确认，Agent 不能绕过责任链路；执行边界，最大轮数、最大耗时、最大 token、置信度阈值都要明确；输出边界，结果要结构化，不能只是一段漂亮的自然语言。

第二，可观测性要从第一天开始。Agent 系统不能只看最终报告。你必须知道它中间做了什么：经过哪些节点、调用哪些工具、消耗多少 token、引用哪些证据、最终分类是什么、人工是否认可。否则你不知道它是真的分析对了，还是碰巧说对了。

第三，工具质量决定 Agent 上限。Anthropic 在文章里提到 Agent-Computer Interface，简称 ACI。很多时候 Agent 表现不好，不是模型不聪明，而是工具对模型不友好：名称太像、参数不清、返回太长、错误不可读、边界不明确。工具描述要像给新同事写操作手册：它解决什么问题，什么时候该用，什么时候不该用，参数怎么填，成功返回什么，失败意味着什么。

第四，Prompt 不要变成知识垃圾场。场景多了以后，角色设定、输出格式、排查步骤、领域术语、历史经验、联系人、止损策略都容易往 Prompt 里塞，最后谁也不敢改。我们的经验是尽早分层：系统指令定义角色和边界，任务指令定义目标和输出，领域知识放进知识库、SOP、规则库或案例库，动态上下文通过工具和检索实时注入，评估标准沉淀到反馈和 Eval Set。

Prompt 应该像任务合同，不应该变成知识仓库。

---

6. 下一步：Eval 自动化和多 Agent 状态协议
   ============================

如果说前 4 个月，我们主要完成了从 Workflow 到 Agent 的架构演进，那么下一阶段最重要的事情，是 Eval。

我们已经有了一些反馈闭环：执行结果可以被人工评价，系统会记录根因分类、工具调用、耗时和分析结果。但这还不够。真正理想的方式，是把历史告警、人工确认过的根因、关键证据和期望输出沉淀成 Eval Set。以后每次改 Prompt、改工具、改 SOP、换模型，都先跑一遍回归评估。

Agent Eval 不能照搬传统单元测试，因为模型输出每次可能不同。它更应该关注：根因分类是否正确，关键证据是否覆盖，风险等级是否合理，建议动作是否安全，不确定时是否承认不确定。

如果没有 Eval，团队只能靠感觉判断“这版好像更聪明了”。但 Agent 工程不能靠感觉。只有把历史案例变成评估集，“只在效果可证明时增加复杂度”才会从一句原则，变成一条工程纪律。

另一个下一步，是多 Agent 编排。我们越来越意识到，多 Agent 的关键不是“怎么串多个 Agent”，而是“怎么定义状态协议”。一个 Agent 完成了部分任务、遇到阻塞、等待人工确认，或者要把上下文交给另一个 Agent，系统必须能表达清楚这些状态。

最少要回答几个问题：任务什么时候创建，子任务如何分配，Agent 什么时候算完成、什么时候算阻塞，需要人工确认时如何暂停和恢复，中间结果如何交接，某个 Agent 失败后谁来重试、降级或回滚。

这看起来不像“智能体”，更像传统状态机。但正是这种传统状态机，决定了 Agent 能不能进生产。没有状态协议，多 Agent 只是多个模型调用堆在一起；有了状态协议，Agent 才能被调度、暂停、恢复、审计和治理。

---

传统产品经理，正在成为下个被淘汰的“传统岗位”。

过去画原型、写 PRD、跟进度的“传统技能包”，在AI时代正迅速贬值。63% 的企业转型做 AI 产品！当下的问题不再是“要不要学 AI ”，而是“如何构建 AI 产品”。

前段时间还跟字节、腾讯的资深 AI 产品经理沟通，他们反馈：在大量招人，只要有 AI 相关的项目经验，基本都能拿到面试机会，而且领导很舍得给钱，涨薪 40-60% 很正常！

01

接下来的产品人，得卷AI能力了！

如今AI大火，行业极速发展的背后，懂AI 产品人才却严重稀缺。这不是要你转技术岗，而是要掌握构建 AI 产品的核心方法：

• 如何将你的领域知识，转化为 AI 产品的核心竞争力？
• 如何用 AI 技术实现你的产品需求？
• 如何设计真正懂用户的 AI 交互体验？
• ……

懂AI，就是产品经理的“救命稻草”！

风口之下，与其焦虑被行业淘汰

不如先人一步享受AI技术带来的红利！

我把AI产品经理的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

（不限年龄！不限岗位！没有代码基础也能学！）

🎁现在扫码，完课还送：

《AI产品面试题库》《AI大模型应用案例集》

02

掌握技术+实战，快速转型！

想成为一名卓越的AI大模型产品经理，需要从技术、到项目实战的全方位转型指南！

**1）**AI产品应用原理解析，产品经理也能听懂！

对于产品经理来说，如果你不懂技术，做不了业务和AI大模型技术衔接、定义不了数据需求，是没法完整的落地一个产品的！

本次课程，专门面向产品经理人群，解析当下最热门的AI产品应用的必备的「大模型」、「多模态」的实际应用和算法原理！解析AI产品应用技术，积累大模型能力！简单易懂，不需要会代码，小白也能掌握！

• 大模型微调：掌握主流大模型（如DeepSeek、Qwen等）的微调技术，针对特定场景优化模型性能。学习如何利用领域数据（如制造、医药、金融等）进行模型定制
• AI Agent智能体搭建：学习如何设计和开发AI Agent，实现多任务协同、自主决策和复杂问题解决。构建垂类场景下的智能助手产品（如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等）

2）超全行业案例解析！

课程详细讲解现阶段，大模型在各个行业和领域的应用现状！包括：零售与电商、教育、医疗、泛娱乐、法律等等10大行业！

详细讲解案例的思路、应用场景，以及背后的技术原理、核心技术！揭秘各个行业、场景的真实现状，和未来产品的发展与机遇！

可以说，讲解完一个案例，就能积累一个AI产品实践的经验！

课程中所涉及到的实战项目，都可以直接在自己的工作中使用，让自己的产品/项目有可借鉴的成功案例！

3）AI产品经理求职专项辅导

课程中会系统的帮助大家拆解字节、腾讯、百度等大厂AI PM岗位JD关键词，掌握AI PM高频面试题型与回答框架；展示 AI 相关能力的关键技巧：Prompt设计、模型评估、A/B测试、成本意识、与算法/工程协作经验；

• To B类AI产品经理：突出“行业理解 + 技术落地 + 商业闭环”能力的简历结构设计，展示项目成果；从客户需求洞察到技术方案设计，展现端到产品思维；如何评估To B AI产品的可行性、客户付费意愿与实施成本
• To C类AI产品经理：拆解头部公司岗位JD，将过往尽力转化为AI产品叙事逻辑；从行业趋势、产品设计题、案例分析&数据分析题、技术理解边界等全流程辅导面试；避免无效海投、锁定最适合的AI产品岗位；

03

本次课程，全程直播讲解，能直接对话大佬和专业助教，不懂就问，超详细的案例，小白也能轻松get！

完课后，还赠送《AI产品经理面试题库》、《AI大模型应用案例集》！不断更新中……

适合人群：

• 想转型AI产品经理、AI项目管理专家、AI产品解决方案等岗位
• 想进行AI产品创业的创业者
• 想成为制作AI产品的程序员
• 想利用AI解决企业问题的管理岗
• 想在AI方向寻找就业方向的毕业生
• AI方向前景广阔、待遇好！

目前，很多产品人已经通过完整学习拿到大厂高薪offer，收入嗷嗷涨！

我把AI产品经理的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】