前端做了六年从业务组件到性能优化从 Vue 到 React 都摸过一遍之后我开始认真考虑一个问题下一个五年前端这个岗位的护城河到底在哪里。正好这段时间关于 Agent 开发的热度一直没降我也陆续看过一些 demo 和教程但真正让我下定决心的是朋友公司的一个真实需求——采购审批流程太繁琐想做一个智能助手。我决定不刷完所谓的 Agent 开发学习路线再动手而是直接拿这个需求当第一个项目边做边学。现在项目已经跑通上线回头整理这篇文章把前端转 Agent 开发这段经历里最关键的东西写出来。这篇文章适合两类人一类是跟我一样想转型、但不知道从哪下手的前端同学另一类是后端或全栈工程师想了解一个带 UI 的 Agent 应用从需求到落地到底要怎么设计。我会把需求拆解、技术选型、工作流设计、踩坑排查完整讲一遍不写空话只讲实际操作。1. 前端干得好好的为什么突然转 Agent 开发讲真前端这个岗位这几年很微妙。框架越来越成熟组件库越来越全业务页面从需求到上线可能就一两天。前端面试题里那些八股比如事件循环、闭包、虚拟 DOM背得再熟日常工作里用到多少大家心里都有数。我并不是说前端没有深度而是前端的深度逐渐集中到了少数人手里——底层框架、工程化、跨端方案、可视化这些方向而大部分前端日常处理的其实是偏执行层面的工作。Agent 开发吸引我的点在于它把“写死逻辑”变成了“描述目标和规则让模型自己规划路径”。同样是代码传统前端写的是“用户点击按钮 - 触发请求 - 渲染数据”Agent 开发写的是“给定一个目标 - 设计工具集 - 设定约束条件和校验规则 - 让模型在多个步骤中自主决策”。前者的复杂度在界面交互和状态流转后者的复杂度在流程编排和不确定性处理。再一个现实原因前端岗位的竞争确实在加剧。2026 年之后的前端面试题越来越卷但岗位数量并没有同比例增长。而 Agent 开发相关岗位无论是 agent 应用开发工程师还是 agent 智能体开发工程师需求正在快速上升很多公司已经把它单独立项。对一个熟悉业务交互、懂用户视角、又具备一定编程能力的前端来说这是一条顺理成章的转型路径。1.1 很多人把 Agent 开发想复杂了其实就是“会规划的工具调用者”我刚开始也有点被概念绕晕什么 ReAct、Plan-and-Execute、多智能体协作、记忆机制听起来一个比一个高级。后来我自己动手做了一个真实项目才明白抛开学术定义一个 Agent 最朴素的本质就是一个大模型 一组工具函数 一套规则和约束。大模型负责理解自然语言、拆解目标、决定调用哪个工具工具函数就是真正执行动作的代码比如查数据库、调接口、发消息规则和约束则是提示词层面的边界——哪些事情允许做哪些不允许输出格式必须是什么。这个结构跟一个前端页面其实很像页面里用户输入是“目标”组件是“工具”路由和状态管理是“规则约束”。语义上有一点必须提前认识到传统前端代码面对的是确定性的输入输出按钮点击一定会触发 click 事件接口返回的 JSON 结构是定义好的。Agent 不一样同一个问题模型这次可能走 A 路径下次可能走 B 路径还会出现调用工具失败后自己换一种策略的情况。这种不确定性不是 bug它是 Agent 存在的意义也是开发方式和传统业务系统最大的区别。1.2 为什么第一步要选真实企业需求而不是按网上路线图刷概念网上关于 Agent 开发学习路线的帖子很多我认真看过几篇内容大多是大模型原理、提示词工程、框架功能、函数调用入门。问题在于这些内容学完之后你还是不知道怎么把一个需求变成 Agent 应用中间缺的就是“真实业务约束”这一环。企业需求会逼你做几件事跟业务方确认业务规则、处理脏数据、设计兜底方案、考虑 token 成本、做超时和重试。这些在教程里学不到只有真实项目才会遇到。以采购审批这个需求为例审批金额阈值是多少、不同部门的审批路径有什么差异、材料缺失时该提示还是该拦截每个细节都需要跟业务方一条条过。而正是这些细节决定了 Agent 的表现上限。如果只是照着官方示例做一个“旅游规划助手”或“文档问答机器人”你练到的只有框架 API 本身。真实需求里你练的是“什么能交给 Agent、什么必须用确定性代码兜底”的判断力这种判断力才是干 Agent 开发的核心竞争力。2. 从朋友公司的痛点切入采购审批智能助手这个需求怎么来的朋友的公司是一家几十人的制造企业内部 OA 系统里采购审批流程走得特别痛苦。业务人员填采购申请单要手动填一堆信息采购类别、预算科目、供应商、预估金额、紧急程度填完之后还要附材料比如报价单、比价记录。审批人拿到申请单之后往往缺乏上下文——搞不清楚这个采购是干什么用的跟哪个项目挂钩只能又去翻附件、查邮件有时候材料缺了就打回业务人员再补来回折腾。这个场景非常适合 Agent信息提取和整理、缺失材料判断、上下文自动关联、审批路径推荐这些本质上都是语义理解和规则判断的组合动作。它们既不像“金额汇总”那样需要 100% 精确计算也不像“权限判断”那样必须交给硬编码因为审批过程中有大量需要“理解上下文”的灰色地带。我花了两周时间跟他们的采购负责人和几个审批人聊需求最后把目标锁定成一个场景业务人员提交申请单和材料后Agent 自动解析填单内容检查材料完备性判断审批路径生成一段给审批人的摘要和建议然后推送待办。审批人可以直接基于摘要做判断不需要再人工翻材料。2.1 需求边界哪些环节适合 Agent 介入哪些必须留给确定性代码这是整个项目我学到最多的部分也是很多 Agent 项目翻车的根源——把不该交给模型的事情硬塞给模型。我整理了一张边界表基本定下了整个系统的分工业务环节处理方式原因金额计算、合计、税率确定性代码计算不允许有半点偏差模型计算不可靠权限校验谁可以审批确定性代码 权限表安全底线必须硬编码审批状态流转确定性代码状态机逻辑不能被模型“自由发挥”申请单语义解析AgentLLM需要理解自然语言中的采购用途、项目关联材料缺失判断Agent 规则校验结合规则做硬校验Agent 判断“材料是否相关”审批摘要生成Agent本质是语言总结模型擅长审批路径推荐Agent 规则表规则表先过滤Agent 做兜底解释这个表格是我跟后端同事一起反复推敲出来的。核心原则就一句话涉及钱、权限、状态的地方永远用代码涉及理解、判断、生成的地方才用 Agent。前端同学对这种边界应该不陌生就好比表单校验里的“必填验证”可以用规则但“这段文本是否与主题相关”就必须靠模型。2.2 技术选型.NET 8 Semantic Kernel Vue3不是拍脑袋选的选型这件事我得诚实说并不是因为我们追求技术时髦而是被现有技术栈捆住的朋友公司整套 OA 系统是 .NET Core 写的数据库 SQL Server后端团队对 Python 没有维护能力。如果硬上一个 Python 系的 Agent 框架后续维护就是灾难。所以后端选了 Semantic Kernel .NET 8。Semantic Kernel 是微软出的 Agent 框架跟 .NET 生态天然亲近插件Plugin机制本质上就是注册一组函数给模型调用跟事件驱动和依赖注入那一套能完美融合。用它写出来的 Agent 能力可以像普通服务一样注入到现有业务系统里不需要额外起一个单独的服务。前端这边毫不意外选了 Vue3 TypeScript。因为我们负责的前端项目本来就是 Vue3 技术栈而且 Vue3 的组合式 API 在处理“Agent 执行状态流”这种场景时非常顺手。数据推送用 SignalR这是 .NET 生态的实时通信方案它能做到服务端主动推消息给前端——Agent 执行过程是异步的执行步骤的分支走向用户需要实时看到如果像传统接口那样前端轮询体验会非常差。这里要特别说明千万不要因为想用某个框架去强行改变公司已有的技术架构。Agent 开发是为了给业务解决问题不是造新轮子。前端同学转型的时候选框架的第一原则应该是“团队能不能维护”其次才是“框架本身好不好”。3. 前端技能的真实迁移四成能复用六成是全新战场转型初期我最关心的问题就是前端那些年积累的东西是不是要清零重来。做完这个项目我可以负责任地说不用清零前端开发的经验在 Agent 开发里至少有四成能直接复用另外六成需要建立新的思维方式。直接复用的部分包括对异步流程的理解、对状态管理的经验、处理复杂用户交互的能力、以及对“用户会怎么操作”的判断力。Agent 开发虽然面向的是模型但最终使用 Agent 的依然是用户一个 Agent 应用好不好用很多体验层面的问题只有做过前端的人才敏感。必须从零学起的是提示词工程、函数描述的编写、Token 成本管理、模型输出的容错设计以及在不确定性中设计兜底方案的能力。这里面每一块都有自己的一套方法论光靠前端经验是覆盖不了的。3.1 用前端概念去理解 Agent组件、依赖数组和状态管理说几个让我“顿悟”的类比这些类比帮我在最短时间内把前端的经验迁移到了 Agent 开发上。组件化开发 - 插件函数设计。做前端时写一个组件要先定义 props 的类型、默认值、事件回调组件之间通过接口通信。Agent 的插件函数设计是完全一样的思路工具函数的参数类型、描述、返回值决定了模型能不能正确调用它。定义函数时写的那段“描述”就好比给组件写文档注释模型只能通过这段描述理解这个函数是干什么的描述含糊函数就白写。useEffect 依赖数组 - Agent 上下文管理。前端开发最头疼的问题是依赖数组写错导致状态不同步。Agent 开发对应的坑是模型能看到的上下文是有限窗口哪些历史消息该保留、哪些该丢弃、哪些该压缩成摘要稍有不慎就会出现“模型忘了前面步骤”的问题。我后来是把“上下文窗口”当 useEffect 的依赖数组来管理的——每次对话前检查一遍确保该在的信息都在不该在的就要主动踢出去。Redux/Vuex 状态管理 - Agent 会话记忆。全局状态和 Agent 会话记忆本质上是同一个问题数据放哪、怎么更新、有效期多长、多个使用者之间怎么隔离。做前端时你对全局 store 的谨慎程度应该原样转移到 Agent 的会话设计上甚至要更谨慎因为模型记住的内容还会无形中影响它的判断。3.2 前端思维在新领域的三个生效场景第一个生效场景是“用户等待体验”。传统前端页面里一个请求超过三秒用户就会焦虑所以要加 loading、骨架屏、进度条。Agent 执行一个完整任务可能要 30 秒甚至更久而且过程中用户完全不知道它在干什么。我把 SignalR 实时推送接到状态流上让前端能逐条展示“正在做信息解析、正在校验材料、正在判断审批路径”效果等同于给大模型加了一个进度条。这件事之所以由我来做是因为我天然觉得“看不到进展就是 bug”。第二个生效场景是“边界状态处理”。前端开发练出来的一个本能任何接口都可能返回空值任何数组都可能越界任何输入都可能是脏数据。这个本能直接迁移到了 Agent 的函数调用设计上——模型返回的结果不会规规矩矩我会在函数调用前做参数校验、调用后做返回校验跟做前端时处理接口返回数据其实是同一套肌肉记忆。第三个生效场景是“数据流转可视化”。前端对数据在组件之间如何流动有天然的敏感。我做的第一个内部调试面板就是把 Agent 每一轮决策记录用户输入、模型调用了哪个函数、参数是什么、返回了什么以结构化列表展示出来跟浏览器 DevTools 的 Network 面板一样。有这个面板后面排查问题效率翻了好几倍。4. 采购审批 Agent 的工作流设计与落地讲完概念进入项目核心部分。这个 Agent 的整体架构是这样Vue3 前端申请填单 审批操作台 - Web API - Semantic Kernel Agent - 插件函数集 - OA 审批系统。前端不再是直接调 CRUD 接口而是提交一个目标后端 Agent 根据目标调度各种函数再通过 SignalR 把执行过程实时返回前端。整个采购审批的处理流程我在设计工作流时拆成了六个阶段接收并标准化申请单前端提交表单大数据 附件信息Agent 负责提取采购用途、项目关联、预算科目等非结构化信息。材料完备性校验先跑硬规则必填字段是否齐全再让 Agent 判断附件是否与采购内容相关。审批路径决策根据金额、类别、预算科目调用部门规则表生成候选审批链。生成审批摘要把申请单要点、材料情况、风险提示整合成一段 200 字以内的摘要给审批人做决策参考。推送到待办调用 OA 待办服务写入审批人的待办列表附带 Agent 的审批建议。处理打回与补料如果审批人打回Agent 重新分析原因生成给业务人员的补料清单。4.1 Agent 的能力通过“插件函数”暴露定义方式跟写接口文档一个道理Semantic Kernel 里Agent 的能力以 Plugin 为单位组织每个 Plugin 下挂若干 Function。写 Function 的定义时我会当成是在写一个给“AI 同事”看的接口文档参数要描述清楚含义和取值范围返回值要说清楚结构还要在描述里补充使用场景和注意事项。举一个实际的例子。审批摘要生成这个函数我最初的定义是[KernelFunction] [Description(根据申请单信息生成审批人摘要)] public async Taskstring GenerateApprovalSummaryAsync( [Description(申请单号)] string orderId, CancellationToken cancellationToken) { // 读取申请单详情、材料附件列表、历史审批记录 // 调用大模型生成摘要 }这里最关键的地方是那个描述文本。模型并不会去看函数的实现代码它只看Description和参数描述来决定“什么情况该调用这个函数、该传什么参数”。我把参数的描述从“申请单号”改成了“申请单号格式如 PO20260101必填需先调用 GetOrderDetail 获取详情”模型调用的准确率明显提升。这个体验相当微妙想想前端的组件 props 校验如果只写orderId: string调用方怎么知道要传什么但组件有 TypeScript 类型撑着模型没有强类型系统它只能靠描述理解。所以我后来给自己定了一条规矩Function 的描述要包含“这个函数是干什么的”“适用什么场景”“参数怎么取值”“有没有前置函数”四要素缺一不可。4.2 审批路径决策规则表和提示词怎么配合审批路径决策是采购场景里最容易出错的一环。如果让模型凭自己的知识去判断“这笔采购应该由哪个副总审批”它大概率会一本正经地给出错误答案因为公司的组织架构和审批层级属于私有知识模型并不知道。我的处理方式是“规则表前置模型兜底”。把一个公司真实的审批规则存在 SQL Server 里代码先做一次确定性查询金额小于 5000 走部门经理审批5000 到 50000 走部门经理 分管副总超过 50000 加总经理涉及固定资产采购无论金额大小都要加财务负责人。这个规则表只负责输出候选审批链。但实际业务总有规则覆盖不到的情况比如某个采购明明金额不大但紧急程度很高业务人员希望加急或者材料里有报价单但金额明细不完整。此时 Agent 的提示词里会写你是一个采购审批规则助手。请结合给定的申请单信息和审批规则链判断当前申请单适合的审批路径。 如果申请单符合规则表中的任一条件严格按规则输出。 如果申请单存在特殊情况例如加急、材料不完整、跨部门协作请解释你判断需要调整审批路径的理由并给出建议路径。 输出格式路径节点列表 理由。规则表负责确定性提示词负责解释确定性之外的情况。两个配合起来整体准确性比我最初只用纯提示词决策高很多。后来我统计了一下方案上线试运行三周路径决策准确率接近 95%剩下的 5% 基本是特殊情况Agent 总能给出合理解释审批人看一眼就能确认。4.3 前端实时反馈用 SignalR 把 Agent 的执行过程推给用户Agent 执行链路要经过模型调用、函数调用、再模型调用每一轮都要花时间。在我做实时反馈之前前端表现就是提交申请后卡在 loading几秒甚至几十秒没有任何回应用户的第一反应是“系统崩了”。我当时的方案是后端在 Agent 执行的每个关键节点上抛出事件开始解析、校验材料、路径决策、摘要生成、推送待办通过 SignalR 推送给指定用户。前端收到后渲染成一个步骤列表用户能实时看到 Agent 当前在做什么。简单的前端代码结构是这样的// Vue3 Composition API const agentSteps refAgentStep[]([]) function onAgentConnection() { // 建立 SignalR 连接 const connection new HubConnectionBuilder() .withUrl(/hubs/agentProcess) .build() connection.on(AgentStepUpdated, (step: AgentStep) { // 把新步骤插入到列表顶部或追加到尾部 agentSteps.value.push({ stepName: step.stepName, status: step.status, // running / completed / failed detail: step.detail, updatedAt: new Date(step.updatedAt) }) }) connection.start() // 提交申请单后调用后端 API 触发 Agent 执行 }实际界面就是顶部一个流程条每个步骤有圆点进行中显示加载动画完成变绿失败变红并展示原因。这个改动看起来简单但对用户体验的提升是决定性的——用户从“不知道系统死没死”变成“知道 Agent 正在一步步处理”。5. 上线调试中踩过的三个坑模型不按套路出牌才是常态任何 Agent 项目开发阶段的框架调用都是顺风顺水的真正的痛苦全部发生在联调测试阶段。我挑三个印象最深的坑出来讲每一个都花了大半天甚至一整天排查希望对后来的人有点帮助。5.1 工具参数解析失败模型把数字当成字符串排查了一下午现象是这样的Agent 调审批路径查询函数时传参偶尔会失败。函数定义的金额参数是int类型但模型有时候会传一个带引号的字符串比如12000.50Semantic Kernel 在做类型的强制转换时直接抛异常Agent 这一轮就中止了。排查链路是这样的先在日志里看到了异常信息指向类型转换失败然后我打开了 Semantic Kernel 的详细日志看到模型实际生成的 tool call 参数确实是{amount: 12000.50, category: 办公用品}。为什么金额会变成字符串我自己的判断是这个函数接入的时候函数参数描述里写了“金额单位元”模型出于“描述得更精确”的动机就把类型加上了引号当成字符串传了。最终方案是双保险。第一把参数描述改得更严格明确写“金额数字类型不要加引号”第二在调用函数前加一层容错转换如果模型传过来的是字符串尝试解析成数字解析失败才报错。这个方案本质上是把模型的输出当成不可靠用户输入来处理这对前端同学来说应该很亲切就好比表单里的 input 明明设了typenumber用户依然可能输入非法字符防一手总没错。5.2 多轮对话丢失前文Agent 忘了自己刚才的判断测试到“打回重审”这个场景时出了鬼业务人员补充材料后再次提交Agent 已经把材料校验过了但生成新一轮审批摘要时它却问“这份申请单的材料在哪里”。也就是说第一轮的校验结果没有进入第二轮模型的上下文。一开始我怀疑是会话记忆配置问题查了半天发现 Semantic Kernel 的ChatHistory对象并没有被清理数据都在。真正的原因是我在函数实现里程序性地把“材料校验结果”写进了一个业务对象但没把它追加回对话历史里去。模型的上下文只包含用户输入和函数返回而材料校验结果字符串并没有写入ChatHistory。修法很简单函数返回的文本如果对后续决策有影响必须显式追加回对话记录。我用前端的方式理解这件事——这就好比全局 store 里更新了一个 state但组件没有重新渲染因为props根本没传进去。版本对了、数据在但组件没收到新数据问题就出在“数据传递链路”上。5.3 用户以为页面卡死其实是模型响应慢链路没有反馈这个问题在正式环境测试时被用户提出来“审批摘要一直不出来页面是不是死了。”我第一反应是接口超时看了后端日志发现服务正常但模型 API 响应耗时达到 37 秒。原因是模型高峰时段排队有时候一次调用就要 20 多秒整个链路串行下来自然超过前端默认超时时间。这个问题不能靠模型侧解决只能在架构上想办法。我把原来的“同步等待完成后一次性返回”改成了“流式响应 分步推送”模型生成摘要时后端以流式方式接收模型输出同时通过 SignalR 把增量内容实时推给前端前端像 ChatGPT 那样逐字展示。加上前面做的步骤状态推送整体体验彻底改观用户能同时看到“进度条 实时输出”。这次改动的额外收益是前端通过 SignalR 接收到的不仅是最终结果还有 Agent 推理过程的关键节点信息这让调试面板的日志变得更完整。流式方案对用户在长耗时场景下的耐心提升非常明显后来我把这个模式复用到其他 Agent 场景成为一种默认做法。6. 给想转型的前端同学的路线建议和个人收尾项目上线后有不少前端同事问我转型的事尤其是“学习路线怎么安排”“要不要先刷几个月面试题再投简历”。我给出的建议跟主流说法不太一样不要先把面试题刷好再做事应该先做事面试题是在做事过程中顺手积累的。当前端面试题越来越卷2026 年的趋势已经很明显了——企业更看重的不是你会背多少八股而是你有没有实际跑通过一个大模型应用有没有踩过工具调用、上下文管理、token 成本这些真实坑。与其花三个月背面试题不如花三个月把一个小型 Agent 应用跑上线。6.1 一份不刷题的学习路线安排我整理一下自己实际的转型路线按时间线排每天大概两到三小时周末多一点阶段时长学习内容产出第一阶段2周大模型 API 调用、提示词基础、结构化输出一个小型问答机器人第二阶段3周函数调用Function Calling、工具定义一个能查天气/查新闻的助手第三阶段4周Semantic Kernel / LangChain 框架、插件机制、会话管理一个多工具业务场景 demo第四阶段6周真实需求开发 流式推送 调试面板可上线的 Agent 应用阶段之间不要跳。很多人一上来就学多智能体协作、复杂记忆机制其实这些在没做过单一 Agent 之前都是空谈。前端同学最大的优势是能自己把 UI 做出来Agent 应用要打磨好前端层面的体验设计是绕不开的这一点往往是纯后端背景的 Agent 开发者最欠缺的。6.2 我个人的一些体会做完这个项目我对“前端转 Agent 开发”这件事有了新的判断。Agent 开发并不是一条跟前端截然分开的赛道它更像是在原有前端能力之上叠加了一层新的“业务能力层”。以前前端写表单、写列表、写审批流现在前端多了一个东西教模型怎么理解业务、怎么使用工具、怎么在不确定中给出确定性的兜底方案。采购审批 Agent 只是我拿第一个真实需求练手的起点。这个工作流的设计模式——规则在前、模型在后、实时反馈贯穿始终——我已经复用到他们公司的其他场景里比如合同审核要点提取、客户咨询自动分类。每复用一个场景我对 Agent 的能力边界就多一分认识。要我说“会写前端”和“会做 Agent 开发”之间真正差的不是框架和 API而是你敢不敢拿一个真实的需求陪着它从出错到稳定从被吐槽到被认可。这个过程中踩到的所有坑都是下一个项目的护城河。
前端做了六年从业务组件到性能优化从 Vue 到 React 都摸过一遍之后我开始认真考虑一个问题下一个五年前端这个岗位的护城河到底在哪里。正好这段时间关于 Agent 开发的热度一直没降我也陆续看过一些 demo 和教程但真正让我下定决心的是朋友公司的一个真实需求——采购审批流程太繁琐想做一个智能助手。我决定不刷完所谓的 Agent 开发学习路线再动手而是直接拿这个需求当第一个项目边做边学。现在项目已经跑通上线回头整理这篇文章把前端转 Agent 开发这段经历里最关键的东西写出来。这篇文章适合两类人一类是跟我一样想转型、但不知道从哪下手的前端同学另一类是后端或全栈工程师想了解一个带 UI 的 Agent 应用从需求到落地到底要怎么设计。我会把需求拆解、技术选型、工作流设计、踩坑排查完整讲一遍不写空话只讲实际操作。1. 前端干得好好的为什么突然转 Agent 开发讲真前端这个岗位这几年很微妙。框架越来越成熟组件库越来越全业务页面从需求到上线可能就一两天。前端面试题里那些八股比如事件循环、闭包、虚拟 DOM背得再熟日常工作里用到多少大家心里都有数。我并不是说前端没有深度而是前端的深度逐渐集中到了少数人手里——底层框架、工程化、跨端方案、可视化这些方向而大部分前端日常处理的其实是偏执行层面的工作。Agent 开发吸引我的点在于它把“写死逻辑”变成了“描述目标和规则让模型自己规划路径”。同样是代码传统前端写的是“用户点击按钮 - 触发请求 - 渲染数据”Agent 开发写的是“给定一个目标 - 设计工具集 - 设定约束条件和校验规则 - 让模型在多个步骤中自主决策”。前者的复杂度在界面交互和状态流转后者的复杂度在流程编排和不确定性处理。再一个现实原因前端岗位的竞争确实在加剧。2026 年之后的前端面试题越来越卷但岗位数量并没有同比例增长。而 Agent 开发相关岗位无论是 agent 应用开发工程师还是 agent 智能体开发工程师需求正在快速上升很多公司已经把它单独立项。对一个熟悉业务交互、懂用户视角、又具备一定编程能力的前端来说这是一条顺理成章的转型路径。1.1 很多人把 Agent 开发想复杂了其实就是“会规划的工具调用者”我刚开始也有点被概念绕晕什么 ReAct、Plan-and-Execute、多智能体协作、记忆机制听起来一个比一个高级。后来我自己动手做了一个真实项目才明白抛开学术定义一个 Agent 最朴素的本质就是一个大模型 一组工具函数 一套规则和约束。大模型负责理解自然语言、拆解目标、决定调用哪个工具工具函数就是真正执行动作的代码比如查数据库、调接口、发消息规则和约束则是提示词层面的边界——哪些事情允许做哪些不允许输出格式必须是什么。这个结构跟一个前端页面其实很像页面里用户输入是“目标”组件是“工具”路由和状态管理是“规则约束”。语义上有一点必须提前认识到传统前端代码面对的是确定性的输入输出按钮点击一定会触发 click 事件接口返回的 JSON 结构是定义好的。Agent 不一样同一个问题模型这次可能走 A 路径下次可能走 B 路径还会出现调用工具失败后自己换一种策略的情况。这种不确定性不是 bug它是 Agent 存在的意义也是开发方式和传统业务系统最大的区别。1.2 为什么第一步要选真实企业需求而不是按网上路线图刷概念网上关于 Agent 开发学习路线的帖子很多我认真看过几篇内容大多是大模型原理、提示词工程、框架功能、函数调用入门。问题在于这些内容学完之后你还是不知道怎么把一个需求变成 Agent 应用中间缺的就是“真实业务约束”这一环。企业需求会逼你做几件事跟业务方确认业务规则、处理脏数据、设计兜底方案、考虑 token 成本、做超时和重试。这些在教程里学不到只有真实项目才会遇到。以采购审批这个需求为例审批金额阈值是多少、不同部门的审批路径有什么差异、材料缺失时该提示还是该拦截每个细节都需要跟业务方一条条过。而正是这些细节决定了 Agent 的表现上限。如果只是照着官方示例做一个“旅游规划助手”或“文档问答机器人”你练到的只有框架 API 本身。真实需求里你练的是“什么能交给 Agent、什么必须用确定性代码兜底”的判断力这种判断力才是干 Agent 开发的核心竞争力。2. 从朋友公司的痛点切入采购审批智能助手这个需求怎么来的朋友的公司是一家几十人的制造企业内部 OA 系统里采购审批流程走得特别痛苦。业务人员填采购申请单要手动填一堆信息采购类别、预算科目、供应商、预估金额、紧急程度填完之后还要附材料比如报价单、比价记录。审批人拿到申请单之后往往缺乏上下文——搞不清楚这个采购是干什么用的跟哪个项目挂钩只能又去翻附件、查邮件有时候材料缺了就打回业务人员再补来回折腾。这个场景非常适合 Agent信息提取和整理、缺失材料判断、上下文自动关联、审批路径推荐这些本质上都是语义理解和规则判断的组合动作。它们既不像“金额汇总”那样需要 100% 精确计算也不像“权限判断”那样必须交给硬编码因为审批过程中有大量需要“理解上下文”的灰色地带。我花了两周时间跟他们的采购负责人和几个审批人聊需求最后把目标锁定成一个场景业务人员提交申请单和材料后Agent 自动解析填单内容检查材料完备性判断审批路径生成一段给审批人的摘要和建议然后推送待办。审批人可以直接基于摘要做判断不需要再人工翻材料。2.1 需求边界哪些环节适合 Agent 介入哪些必须留给确定性代码这是整个项目我学到最多的部分也是很多 Agent 项目翻车的根源——把不该交给模型的事情硬塞给模型。我整理了一张边界表基本定下了整个系统的分工业务环节处理方式原因金额计算、合计、税率确定性代码计算不允许有半点偏差模型计算不可靠权限校验谁可以审批确定性代码 权限表安全底线必须硬编码审批状态流转确定性代码状态机逻辑不能被模型“自由发挥”申请单语义解析AgentLLM需要理解自然语言中的采购用途、项目关联材料缺失判断Agent 规则校验结合规则做硬校验Agent 判断“材料是否相关”审批摘要生成Agent本质是语言总结模型擅长审批路径推荐Agent 规则表规则表先过滤Agent 做兜底解释这个表格是我跟后端同事一起反复推敲出来的。核心原则就一句话涉及钱、权限、状态的地方永远用代码涉及理解、判断、生成的地方才用 Agent。前端同学对这种边界应该不陌生就好比表单校验里的“必填验证”可以用规则但“这段文本是否与主题相关”就必须靠模型。2.2 技术选型.NET 8 Semantic Kernel Vue3不是拍脑袋选的选型这件事我得诚实说并不是因为我们追求技术时髦而是被现有技术栈捆住的朋友公司整套 OA 系统是 .NET Core 写的数据库 SQL Server后端团队对 Python 没有维护能力。如果硬上一个 Python 系的 Agent 框架后续维护就是灾难。所以后端选了 Semantic Kernel .NET 8。Semantic Kernel 是微软出的 Agent 框架跟 .NET 生态天然亲近插件Plugin机制本质上就是注册一组函数给模型调用跟事件驱动和依赖注入那一套能完美融合。用它写出来的 Agent 能力可以像普通服务一样注入到现有业务系统里不需要额外起一个单独的服务。前端这边毫不意外选了 Vue3 TypeScript。因为我们负责的前端项目本来就是 Vue3 技术栈而且 Vue3 的组合式 API 在处理“Agent 执行状态流”这种场景时非常顺手。数据推送用 SignalR这是 .NET 生态的实时通信方案它能做到服务端主动推消息给前端——Agent 执行过程是异步的执行步骤的分支走向用户需要实时看到如果像传统接口那样前端轮询体验会非常差。这里要特别说明千万不要因为想用某个框架去强行改变公司已有的技术架构。Agent 开发是为了给业务解决问题不是造新轮子。前端同学转型的时候选框架的第一原则应该是“团队能不能维护”其次才是“框架本身好不好”。3. 前端技能的真实迁移四成能复用六成是全新战场转型初期我最关心的问题就是前端那些年积累的东西是不是要清零重来。做完这个项目我可以负责任地说不用清零前端开发的经验在 Agent 开发里至少有四成能直接复用另外六成需要建立新的思维方式。直接复用的部分包括对异步流程的理解、对状态管理的经验、处理复杂用户交互的能力、以及对“用户会怎么操作”的判断力。Agent 开发虽然面向的是模型但最终使用 Agent 的依然是用户一个 Agent 应用好不好用很多体验层面的问题只有做过前端的人才敏感。必须从零学起的是提示词工程、函数描述的编写、Token 成本管理、模型输出的容错设计以及在不确定性中设计兜底方案的能力。这里面每一块都有自己的一套方法论光靠前端经验是覆盖不了的。3.1 用前端概念去理解 Agent组件、依赖数组和状态管理说几个让我“顿悟”的类比这些类比帮我在最短时间内把前端的经验迁移到了 Agent 开发上。组件化开发 - 插件函数设计。做前端时写一个组件要先定义 props 的类型、默认值、事件回调组件之间通过接口通信。Agent 的插件函数设计是完全一样的思路工具函数的参数类型、描述、返回值决定了模型能不能正确调用它。定义函数时写的那段“描述”就好比给组件写文档注释模型只能通过这段描述理解这个函数是干什么的描述含糊函数就白写。useEffect 依赖数组 - Agent 上下文管理。前端开发最头疼的问题是依赖数组写错导致状态不同步。Agent 开发对应的坑是模型能看到的上下文是有限窗口哪些历史消息该保留、哪些该丢弃、哪些该压缩成摘要稍有不慎就会出现“模型忘了前面步骤”的问题。我后来是把“上下文窗口”当 useEffect 的依赖数组来管理的——每次对话前检查一遍确保该在的信息都在不该在的就要主动踢出去。Redux/Vuex 状态管理 - Agent 会话记忆。全局状态和 Agent 会话记忆本质上是同一个问题数据放哪、怎么更新、有效期多长、多个使用者之间怎么隔离。做前端时你对全局 store 的谨慎程度应该原样转移到 Agent 的会话设计上甚至要更谨慎因为模型记住的内容还会无形中影响它的判断。3.2 前端思维在新领域的三个生效场景第一个生效场景是“用户等待体验”。传统前端页面里一个请求超过三秒用户就会焦虑所以要加 loading、骨架屏、进度条。Agent 执行一个完整任务可能要 30 秒甚至更久而且过程中用户完全不知道它在干什么。我把 SignalR 实时推送接到状态流上让前端能逐条展示“正在做信息解析、正在校验材料、正在判断审批路径”效果等同于给大模型加了一个进度条。这件事之所以由我来做是因为我天然觉得“看不到进展就是 bug”。第二个生效场景是“边界状态处理”。前端开发练出来的一个本能任何接口都可能返回空值任何数组都可能越界任何输入都可能是脏数据。这个本能直接迁移到了 Agent 的函数调用设计上——模型返回的结果不会规规矩矩我会在函数调用前做参数校验、调用后做返回校验跟做前端时处理接口返回数据其实是同一套肌肉记忆。第三个生效场景是“数据流转可视化”。前端对数据在组件之间如何流动有天然的敏感。我做的第一个内部调试面板就是把 Agent 每一轮决策记录用户输入、模型调用了哪个函数、参数是什么、返回了什么以结构化列表展示出来跟浏览器 DevTools 的 Network 面板一样。有这个面板后面排查问题效率翻了好几倍。4. 采购审批 Agent 的工作流设计与落地讲完概念进入项目核心部分。这个 Agent 的整体架构是这样Vue3 前端申请填单 审批操作台 - Web API - Semantic Kernel Agent - 插件函数集 - OA 审批系统。前端不再是直接调 CRUD 接口而是提交一个目标后端 Agent 根据目标调度各种函数再通过 SignalR 把执行过程实时返回前端。整个采购审批的处理流程我在设计工作流时拆成了六个阶段接收并标准化申请单前端提交表单大数据 附件信息Agent 负责提取采购用途、项目关联、预算科目等非结构化信息。材料完备性校验先跑硬规则必填字段是否齐全再让 Agent 判断附件是否与采购内容相关。审批路径决策根据金额、类别、预算科目调用部门规则表生成候选审批链。生成审批摘要把申请单要点、材料情况、风险提示整合成一段 200 字以内的摘要给审批人做决策参考。推送到待办调用 OA 待办服务写入审批人的待办列表附带 Agent 的审批建议。处理打回与补料如果审批人打回Agent 重新分析原因生成给业务人员的补料清单。4.1 Agent 的能力通过“插件函数”暴露定义方式跟写接口文档一个道理Semantic Kernel 里Agent 的能力以 Plugin 为单位组织每个 Plugin 下挂若干 Function。写 Function 的定义时我会当成是在写一个给“AI 同事”看的接口文档参数要描述清楚含义和取值范围返回值要说清楚结构还要在描述里补充使用场景和注意事项。举一个实际的例子。审批摘要生成这个函数我最初的定义是[KernelFunction] [Description(根据申请单信息生成审批人摘要)] public async Taskstring GenerateApprovalSummaryAsync( [Description(申请单号)] string orderId, CancellationToken cancellationToken) { // 读取申请单详情、材料附件列表、历史审批记录 // 调用大模型生成摘要 }这里最关键的地方是那个描述文本。模型并不会去看函数的实现代码它只看Description和参数描述来决定“什么情况该调用这个函数、该传什么参数”。我把参数的描述从“申请单号”改成了“申请单号格式如 PO20260101必填需先调用 GetOrderDetail 获取详情”模型调用的准确率明显提升。这个体验相当微妙想想前端的组件 props 校验如果只写orderId: string调用方怎么知道要传什么但组件有 TypeScript 类型撑着模型没有强类型系统它只能靠描述理解。所以我后来给自己定了一条规矩Function 的描述要包含“这个函数是干什么的”“适用什么场景”“参数怎么取值”“有没有前置函数”四要素缺一不可。4.2 审批路径决策规则表和提示词怎么配合审批路径决策是采购场景里最容易出错的一环。如果让模型凭自己的知识去判断“这笔采购应该由哪个副总审批”它大概率会一本正经地给出错误答案因为公司的组织架构和审批层级属于私有知识模型并不知道。我的处理方式是“规则表前置模型兜底”。把一个公司真实的审批规则存在 SQL Server 里代码先做一次确定性查询金额小于 5000 走部门经理审批5000 到 50000 走部门经理 分管副总超过 50000 加总经理涉及固定资产采购无论金额大小都要加财务负责人。这个规则表只负责输出候选审批链。但实际业务总有规则覆盖不到的情况比如某个采购明明金额不大但紧急程度很高业务人员希望加急或者材料里有报价单但金额明细不完整。此时 Agent 的提示词里会写你是一个采购审批规则助手。请结合给定的申请单信息和审批规则链判断当前申请单适合的审批路径。 如果申请单符合规则表中的任一条件严格按规则输出。 如果申请单存在特殊情况例如加急、材料不完整、跨部门协作请解释你判断需要调整审批路径的理由并给出建议路径。 输出格式路径节点列表 理由。规则表负责确定性提示词负责解释确定性之外的情况。两个配合起来整体准确性比我最初只用纯提示词决策高很多。后来我统计了一下方案上线试运行三周路径决策准确率接近 95%剩下的 5% 基本是特殊情况Agent 总能给出合理解释审批人看一眼就能确认。4.3 前端实时反馈用 SignalR 把 Agent 的执行过程推给用户Agent 执行链路要经过模型调用、函数调用、再模型调用每一轮都要花时间。在我做实时反馈之前前端表现就是提交申请后卡在 loading几秒甚至几十秒没有任何回应用户的第一反应是“系统崩了”。我当时的方案是后端在 Agent 执行的每个关键节点上抛出事件开始解析、校验材料、路径决策、摘要生成、推送待办通过 SignalR 推送给指定用户。前端收到后渲染成一个步骤列表用户能实时看到 Agent 当前在做什么。简单的前端代码结构是这样的// Vue3 Composition API const agentSteps refAgentStep[]([]) function onAgentConnection() { // 建立 SignalR 连接 const connection new HubConnectionBuilder() .withUrl(/hubs/agentProcess) .build() connection.on(AgentStepUpdated, (step: AgentStep) { // 把新步骤插入到列表顶部或追加到尾部 agentSteps.value.push({ stepName: step.stepName, status: step.status, // running / completed / failed detail: step.detail, updatedAt: new Date(step.updatedAt) }) }) connection.start() // 提交申请单后调用后端 API 触发 Agent 执行 }实际界面就是顶部一个流程条每个步骤有圆点进行中显示加载动画完成变绿失败变红并展示原因。这个改动看起来简单但对用户体验的提升是决定性的——用户从“不知道系统死没死”变成“知道 Agent 正在一步步处理”。5. 上线调试中踩过的三个坑模型不按套路出牌才是常态任何 Agent 项目开发阶段的框架调用都是顺风顺水的真正的痛苦全部发生在联调测试阶段。我挑三个印象最深的坑出来讲每一个都花了大半天甚至一整天排查希望对后来的人有点帮助。5.1 工具参数解析失败模型把数字当成字符串排查了一下午现象是这样的Agent 调审批路径查询函数时传参偶尔会失败。函数定义的金额参数是int类型但模型有时候会传一个带引号的字符串比如12000.50Semantic Kernel 在做类型的强制转换时直接抛异常Agent 这一轮就中止了。排查链路是这样的先在日志里看到了异常信息指向类型转换失败然后我打开了 Semantic Kernel 的详细日志看到模型实际生成的 tool call 参数确实是{amount: 12000.50, category: 办公用品}。为什么金额会变成字符串我自己的判断是这个函数接入的时候函数参数描述里写了“金额单位元”模型出于“描述得更精确”的动机就把类型加上了引号当成字符串传了。最终方案是双保险。第一把参数描述改得更严格明确写“金额数字类型不要加引号”第二在调用函数前加一层容错转换如果模型传过来的是字符串尝试解析成数字解析失败才报错。这个方案本质上是把模型的输出当成不可靠用户输入来处理这对前端同学来说应该很亲切就好比表单里的 input 明明设了typenumber用户依然可能输入非法字符防一手总没错。5.2 多轮对话丢失前文Agent 忘了自己刚才的判断测试到“打回重审”这个场景时出了鬼业务人员补充材料后再次提交Agent 已经把材料校验过了但生成新一轮审批摘要时它却问“这份申请单的材料在哪里”。也就是说第一轮的校验结果没有进入第二轮模型的上下文。一开始我怀疑是会话记忆配置问题查了半天发现 Semantic Kernel 的ChatHistory对象并没有被清理数据都在。真正的原因是我在函数实现里程序性地把“材料校验结果”写进了一个业务对象但没把它追加回对话历史里去。模型的上下文只包含用户输入和函数返回而材料校验结果字符串并没有写入ChatHistory。修法很简单函数返回的文本如果对后续决策有影响必须显式追加回对话记录。我用前端的方式理解这件事——这就好比全局 store 里更新了一个 state但组件没有重新渲染因为props根本没传进去。版本对了、数据在但组件没收到新数据问题就出在“数据传递链路”上。5.3 用户以为页面卡死其实是模型响应慢链路没有反馈这个问题在正式环境测试时被用户提出来“审批摘要一直不出来页面是不是死了。”我第一反应是接口超时看了后端日志发现服务正常但模型 API 响应耗时达到 37 秒。原因是模型高峰时段排队有时候一次调用就要 20 多秒整个链路串行下来自然超过前端默认超时时间。这个问题不能靠模型侧解决只能在架构上想办法。我把原来的“同步等待完成后一次性返回”改成了“流式响应 分步推送”模型生成摘要时后端以流式方式接收模型输出同时通过 SignalR 把增量内容实时推给前端前端像 ChatGPT 那样逐字展示。加上前面做的步骤状态推送整体体验彻底改观用户能同时看到“进度条 实时输出”。这次改动的额外收益是前端通过 SignalR 接收到的不仅是最终结果还有 Agent 推理过程的关键节点信息这让调试面板的日志变得更完整。流式方案对用户在长耗时场景下的耐心提升非常明显后来我把这个模式复用到其他 Agent 场景成为一种默认做法。6. 给想转型的前端同学的路线建议和个人收尾项目上线后有不少前端同事问我转型的事尤其是“学习路线怎么安排”“要不要先刷几个月面试题再投简历”。我给出的建议跟主流说法不太一样不要先把面试题刷好再做事应该先做事面试题是在做事过程中顺手积累的。当前端面试题越来越卷2026 年的趋势已经很明显了——企业更看重的不是你会背多少八股而是你有没有实际跑通过一个大模型应用有没有踩过工具调用、上下文管理、token 成本这些真实坑。与其花三个月背面试题不如花三个月把一个小型 Agent 应用跑上线。6.1 一份不刷题的学习路线安排我整理一下自己实际的转型路线按时间线排每天大概两到三小时周末多一点阶段时长学习内容产出第一阶段2周大模型 API 调用、提示词基础、结构化输出一个小型问答机器人第二阶段3周函数调用Function Calling、工具定义一个能查天气/查新闻的助手第三阶段4周Semantic Kernel / LangChain 框架、插件机制、会话管理一个多工具业务场景 demo第四阶段6周真实需求开发 流式推送 调试面板可上线的 Agent 应用阶段之间不要跳。很多人一上来就学多智能体协作、复杂记忆机制其实这些在没做过单一 Agent 之前都是空谈。前端同学最大的优势是能自己把 UI 做出来Agent 应用要打磨好前端层面的体验设计是绕不开的这一点往往是纯后端背景的 Agent 开发者最欠缺的。6.2 我个人的一些体会做完这个项目我对“前端转 Agent 开发”这件事有了新的判断。Agent 开发并不是一条跟前端截然分开的赛道它更像是在原有前端能力之上叠加了一层新的“业务能力层”。以前前端写表单、写列表、写审批流现在前端多了一个东西教模型怎么理解业务、怎么使用工具、怎么在不确定中给出确定性的兜底方案。采购审批 Agent 只是我拿第一个真实需求练手的起点。这个工作流的设计模式——规则在前、模型在后、实时反馈贯穿始终——我已经复用到他们公司的其他场景里比如合同审核要点提取、客户咨询自动分类。每复用一个场景我对 Agent 的能力边界就多一分认识。要我说“会写前端”和“会做 Agent 开发”之间真正差的不是框架和 API而是你敢不敢拿一个真实的需求陪着它从出错到稳定从被吐槽到被认可。这个过程中踩到的所有坑都是下一个项目的护城河。
