做 Agent 别先选框架，先选一个业务系统

前端出身，跨进智能体这个坑已经有一段时间了。写这个系列，是想把自己摸索的过程留下来。不是教程，是记录。同在学习路上的，可以看看我整理的电子书：https://book.zyh.lol，共勉。

很多人一说要做 Agent，第一反应是研究技术栈：LangGraph 还是 CrewAI？要不要多 Agent、RAG、记忆系统、MCP？模型选 GPT、Claude 还是 DeepSeek？

这些问题都重要，但从技术名词出发，最后做出来的多半是"看起来很智能、业务上不知道放哪里"的聊天框。

换个起点会更稳：先找一个具体的业务系统。比如公司内部的 IMS。

IMS 里已经有员工、项目、工时、客户、请假、销售记录、需求池、迭代计划、里程碑、风险台账、制度文档。过去大家用它的方式，是打开页面、点菜单、筛表格、查记录、填表单。

如果给 IMS 加一个 Agent，交互会变成另一种样子。

研发可以直接问：

我这周哪天工时没填？
过去一个月我主要做了哪些项目？
每个项目分别投入了多少时间？
公司请假制度是什么？
我现在还有多少调休？

销售可以直接问：

这个客户最近是什么状态？
帮我给这个客户打几个标签。
我上传一段和客户的电销录音，你帮我分析客户意愿。
这个客户现在成交可能性高吗？
下次沟通我应该怎么说？

产品经理可以直接问：

这个需求现在卡在哪个阶段？
最近一周用户反馈最多的问题是什么？
帮我把这些客户反馈归类成需求主题。
这个版本还有哪些需求没有验收？
根据当前进度，帮我生成一份版本说明草稿。

PMO 可以直接问：

本周有哪些项目存在延期风险？
哪些项目的工时投入和计划偏差最大？
这个里程碑为什么一直没有关闭？
帮我汇总本月各项目的资源投入和风险点。
哪些跨部门事项需要我推动？

这时候，Agent 就不再只是一个问答机器人了。

它变成了 IMS 系统的新入口：能理解岗位、读取业务数据、查询公司制度、分析语音内容、给出下一步建议，还能把过程沉淀下来，成为后续工作的上下文。

所以，如果你也想做一个自己的 Agent，真正的起点不是“我要选哪个框架”，而是：

这个 Agent 要进入哪个业务系统？面向哪些岗位？解决哪些高频、重复、可验证的问题？

不要先做通用 Agent，先做岗位 Agent

公司里的不同岗位，真正需要的 Agent 完全不一样。

研发关心的是工时、项目、任务、缺漏提醒。
销售关心的是客户、沟通、意愿、跟进策略。
产品经理关心的是需求、反馈、版本、验收和优先级。
PMO 关心的是里程碑、风险、资源、依赖和项目偏差。
HR 和行政关心的是制度、请假、调休、审批流程。
管理者关心的是团队投入、项目进展、客户状态和风险预警。

如果一开始就说“我要做一个公司万能助手”，范围会非常大，最后很容易变成什么都能聊一点，但什么都做不深。

更合理的方式，是先按岗位拆。

这一步很关键。

因为 Agent 不是越通用越好。真实业务里，越通用，越难评估；越具体，越容易上线。

一个好的起点是：先找一个岗位，选 3 到 5 个高频问题，把它们做成闭环。

比如先做研发侧：

• 查询本周哪些天工时没填。
• 汇总过去一个月参与过哪些项目。
• 统计每个项目投入了多少工时。
• 查询公司请假制度。
• 查询个人调休余额。

再做销售侧：

• 查询客户基础信息。
• 给客户打标签。
• 上传电销录音并转写。
• 分析客户意愿、态度和异议点。
• 生成下次沟通建议和客户评分。

再扩到产品经理侧：

• 查询需求当前状态和负责人。
• 汇总最近一周用户反馈。
• 把客户反馈聚类成需求主题。
• 生成版本说明和验收清单草稿。
• 提醒延期需求和阻塞原因。

再扩到 PMO 侧：

• 汇总项目里程碑完成情况。
• 识别延期风险和资源投入偏差。
• 整理跨部门依赖和待推动事项。
• 生成项目周报草稿。
• 对异常项目给出风险说明。

这就已经不是“聊天”了，而是在把一个业务系统里的常见操作，变成自然语言入口。

第一版不要追求全自动

很多 Agent 项目一开始就想做全自动。

全自动填工时、全自动改客户标签、全自动判断客户成交概率、全自动发送跟进消息。听起来很酷，但风险也很高。

更稳妥的方式是：第一版先做人机协作。

研发问“我哪天工时没填”，Agent 可以查询工时系统，返回缺失日期，并给出补填入口。

销售上传一段电销录音，Agent 可以先转写，再分析客户意愿、异议点和下次沟通建议，但最终标签和评分由销售确认。

产品经理让 Agent 汇总用户反馈，Agent 可以先做分类、去重、主题提炼和需求草稿，但最终是否进入版本计划，要由产品经理确认。

PMO 让 Agent 判断项目风险，Agent 可以先汇总延期信号、资源偏差和阻塞事项，但不能直接替项目负责人下结论，更不能自动修改项目状态。

员工问请假制度，Agent 可以从公司制度文档里检索答案，并附上依据。

员工问调休余额，Agent 可以调用 IMS 接口查询个人余额，但不会替用户直接发起请假申请，除非用户明确确认。

也就是说，V1 的目标不是替人做完所有事，而是先把查找、整理、分析、建议这几类重复劳动接过去。

这不是保守，而是生产系统里很重要的边界感。

Agent 第一版真正要证明的是：它能不能稳定减少人的重复操作，而不是能不能从第一天开始替人做决策。

IMS Agent 的架构应该怎么拆

一个可落地的 IMS Agent，通常不是一个简单 prompt，而是一套业务能力组合。

它至少需要下面几层：

用户问题 ↓身份与权限层：识别用户是谁、属于什么岗位、能看哪些数据 ↓意图路由层：判断是查工时、查客户、查制度，还是分析录音 ↓上下文构建层：组装用户信息、业务数据、制度文档、历史记录 ↓业务工具层：调用 IMS、CRM、请假、工时、客户、需求、项目等系统接口 ↓知识检索层：查询公司制度、销售 SOP、项目规范、产品资料、需求规范 ↓技能执行层：按固定流程完成工时汇总、客户分析、需求整理、项目周报 ↓安全与审计层：检查权限、记录操作、高风险动作要求确认 ↓最终回复：给出答案、建议、入口或待确认动作

这里真正困难的地方，不是怎么调用大模型，而是怎么把 Agent 接进业务系统。

没有权限控制，销售可能看到不该看的客户。
没有审计记录，Agent 做过什么很难追踪。
没有业务 API，Agent 只能聊天，不能查询真实数据。
没有制度文档检索，它回答请假政策时就容易胡说。
没有操作确认，它可能在不该自动执行的地方越权。

所以业务 Agent 的核心，不是模型，而是系统连接能力。

不同需求，对应不同技术能力

IMS Agent 里会同时出现很多技术名词，但它们不是堆上去的，而是被业务问题自然推出来的。

一句话：RAG不是为了显得高级，而是因为公司制度需要被检索；Tool Calling不是炫技，而是 Agent 必须查询真实业务数据；Memory不是把聊天记录塞回去，而是记录客户历史和项目上下文；Skills不是简单提示词，而是把"分析通话"“汇总工时”“整理反馈”"生成周报"沉淀成稳定流程。子 Agent 也不是一开始就要有，而是任务复杂到需要分工时才引入。

比如销售上传一段客户通话录音，背后可以拆成这样一条链路：

录音上传 -> 语音转写 -> 提取客户问题 -> 判断客户态度 -> 识别异议点 -> 生成客户标签 -> 给出意愿评分 -> 生成下次沟通建议 -> 人工确认后写回 CRM

早期可以由一个 Agent 完成。等业务复杂后，再拆成转写 Agent、客户画像 Agent、评分 Agent、沟通建议 Agent。

技术选型应该从业务复杂度反推

很多团队选型时会反过来：先定框架，再把业务往框架里塞。

更稳的方式是先问业务复杂度。

如果只是查工时、查调休、查客户基础信息，原生代码 + Function Calling 就够了。先把权限、接口、日志和错误处理做好，比上复杂框架更重要。

如果任务开始出现多步骤状态，比如“先查客户，分析历史沟通，再生成跟进建议，最后写回 CRM”，这时可以考虑引入状态机式编排，比如 LangGraph 这类工具。

如果任务天然需要不同角色分工，比如销售录音分析里有转写、质检、评分、策略建议，而且每一步都需要独立提示词和独立评估标准，再考虑多 Agent。

如果知识来自公司制度、销售 SOP、产品资料、项目规范，就需要 RAG。但要注意，RAG 解决的是外部知识可达性，不要把用户偏好、客户历史、任务状态全丢进同一个知识库里。

如果 Agent 要跨会话持续理解客户、员工和项目，就需要记忆系统。但记忆应该有类型、有效期、来源和撤销机制，不是无限追加聊天记录。

一句话总结：

框架不是 Agent 的起点，业务复杂度才是。

第一版 IMS Agent 可以怎么落地

如果让我设计 IMS Agent 的第一版，我不会先做"大而全的公司助手"，而是分阶段推进：

• 第一阶段：先做研发和销售两个闭环（前面第二节列过任务清单），验证数据查询和录音分析两条链路。
• 第二阶段：扩到产品经理，验证反馈聚类和版本助手能力。
• 第三阶段：扩到 PMO，验证多源数据汇总和风险识别能力。

之所以从研发和销售切入，是因为这两个闭环有几个共同特点：

第一，数据已经在 IMS 或相关系统里，不需要额外采集。
第二，问题高频，员工每天都在重复做。
第三，结果容易验证（工时对不对、客户分析准不准，业务方一眼能看出来）。
第四，失败可以兜底，最差就是回退到原来手动操作。
第五，能逐步积累反馈数据，为后续优化提供素材。

这比一开始做一个"什么都能问的公司 Agent"更靠谱。

上线后也不要只看用户觉得"聪不聪明"，而是看更具体的指标：

Agent 能不能上线，不应该只靠 Demo 演示，而应该靠这些指标证明。

最后再谈"灵魂"

前面讲了架构、接口、RAG、Skills、记忆和子 Agent，那 Agent 的"灵魂"到底是什么？

它不是玄学。可以用一个对比说清楚。

研发问"我这周哪天工时没填"。

• 没灵魂的 Agent 会答：“请打开工时系统的考勤模块，在右上角筛选本周日期范围进行查看。”——本质是把帮助文档复读了一遍，用户看完还得自己去点。
• 有灵魂的 Agent 会答：“你周二、周四的工时还没填，周二涉及项目 A 和项目 C，周四涉及项目 B，是否现在补填？”——它读了工时系统、关联了项目，并把下一步动作放在面前。

差别不在模型多强，而在它有没有真正进入业务。具体说，是三件事：

第一，它懂岗位。同样问"风险"，对销售意味着客户流失信号，对 PMO 意味着里程碑延期。Agent 必须知道当前用户是谁、关心什么。

第二，它懂业务规则。员工问请假制度，它不能凭模型记忆乱答，而要从公司制度文档检索，并附上依据。

第三，它懂历史上下文。销售分析客户时，它不只看这一通电话，还能结合历史沟通、标签变化、上次异议点和当前阶段。

一个没有业务连接的 Agent，只是在聊天。一个接入了 IMS、CRM、制度文档、工时、需求池、项目计划和客户历史的 Agent，才开始变成真正的业务智能入口。

所以，如果你也想做一个自己的 Agent，不要从框架开始：

先找一个已经存在的业务系统 → 再找一个岗位 → 再找几个每天都在重复发生的问题 → 把查询、整理、分析、建议这几个环节先做成闭环 → 然后再逐步加入 RAG、Skills、Memory、子 Agent、权限审计和人工确认。

Agent 的价值，不在于它看起来多像人，而在于它能不能进入真实业务，把原来分散在系统、文档、流程和经验里的东西，重新组织成一个更自然的工作入口。

这才是做一个自己的 Agent，最值得开始的地方。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

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

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