1. 一个前端为什么会去碰 Agent 开发

先说结论：Agent 开发跟模型训练，基本是两码事。我做了六年前端，去年开始接手一个内部工具链的智能化改造，当时听到“Agent”这个词，第一反应是“这玩意儿是不是得先学 PyTorch，再搞几张显卡”。结果真正上手之后发现，前端做 Agent 开发，核心能力栈跟写业务代码的重合度比我预想的高得多——你不需要训练模型，你需要的是把模型当成一个能力接口来编排。

这个认知转变花了我大概两周。前一周我一直在看各种模型微调的资料，越看越焦虑，觉得自己要从零补数学。后来一位做后端的同事点了我一句：“你调用第三方支付接口的时候，会去研究银行的核心系统怎么实现吗？”这句话直接把我拉回正轨。Agent 开发的本质是编排与调度，不是训练与调参。

所以这篇内容适合谁看？三类人：一是跟我一样的前端，想搞清楚 Agent 到底是不是自己的菜；二是刚接触这个概念、被“大模型”三个字吓住的开发者；三是已经在做业务系统、想把手头的工具链串成自动化流程的技术人员。我会把整个认知路径、实操中踩过的坑、以及前端视角下最顺手的方案选型讲清楚，不涉及任何模型训练层面的数学推导，因为那确实不是这个岗位该操心的部分。

核心关键词就几个：Agent 开发、前端视角、模型调用、工具编排、认知边界。下面我按自己实际走过的路来拆。

2. 先把概念掰开：Agent 开发和模型训练到底差在哪

2.1 一个生活化的类比：餐厅后厨 vs 餐厅经理

模型训练像是培养一个厨师。你要准备食材（数据）、反复试菜（训练）、调整火候和配方（调参），最终目标是让这个厨师能独立做出一桌好菜。这个过程需要大量算力、大量时间，而且厨师一旦定型，想改口味就得重新培养。

Agent 开发则像是当餐厅经理。你不需要会炒菜，你需要做的是：知道哪个厨师擅长什么菜（模型能力边界）、怎么把订单拆解成多个厨师的协作任务（任务编排）、客人催单时怎么调度（异常处理）、以及什么时候该让厨师重做（结果校验）。经理的核心能力是协调资源达成目标，而不是亲自掌勺。

这个类比基本能解释我前两周的困惑：我一直在试图学“炒菜”，但实际上我的岗位需要的是“排班和调度”。

2.2 技术层面的边界划分

从技术实现角度看，两者的差异可以用一张表说清楚：

我实测下来的感受是，Agent 开发中 80% 的工作量在流程设计和边界处理上，剩下 20% 才是跟模型本身打交道。而前端日常做的状态管理、异步流程控制、错误处理，恰好就是 Agent 编排最需要的能力。

2.3 为什么前端做这件事有天然优势

前端天天在处理“用户输入不确定、系统状态多变、需要给用户即时反馈”的场景。Agent 开发面对的问题几乎一模一样：模型的输出是不确定的、工具调用的结果可能失败、整个流程需要可观测。你在写表单校验时积累的防御性编程思维，在 Agent 开发里直接就能用上。

另外，前端对接口调用这件事的熟练度是被低估的。Agent 开发里大量的工作是把模型输出解析成结构化数据、再调用下一个工具、再把结果拼回去。这套“请求-解析-转发”的模式，跟前端调 REST API 没有本质区别，只是多了一层自然语言的不确定性。

3. 前端做 Agent 开发，核心能力栈怎么搭

3.1 必须掌握的三个基础能力

第一是提示词工程的基础认知。不是让你去研究什么玄学提示词，而是要理解：模型对指令的遵循是有概率的，同样的输入可能得到不同输出。你需要学会用结构化的方式写指令，比如明确角色、明确输出格式、给出示例。我自己的习惯是把提示词当成一份接口文档来写——输入是什么、输出是什么、异常情况怎么处理，全部写清楚。

第二是工具调用的编排能力。Agent 之所以是 Agent，是因为它能调用外部工具。前端最熟悉的就是各种 API 调用，这里只是把“调用后端接口”换成了“让模型决定调用哪个接口”。你需要设计的是：有哪些工具可用、每个工具的入参出参是什么、模型怎么知道该用哪个工具。

第三是流程控制与状态管理。一个完整的 Agent 任务往往需要多轮交互，中间状态怎么存、失败了怎么重试、超时了怎么降级，这些跟前端做复杂表单流程的思路完全一致。我用的是类似 Redux 的状态机思路，把 Agent 的每一步都当成一个状态节点来管理。

3.2 可以暂时不碰的东西

模型微调、分布式训练、CUDA 编程、Transformer 底层原理——这些在 Agent 开发的前期完全不需要。我并不是说这些不重要，而是说它们不属于这个岗位的核心职责。就像前端不需要懂浏览器内核的 C++ 实现，也能写出高性能页面。

当然，如果你后续想深入做模型能力评估、或者需要针对特定场景优化模型表现，那时候再去补这些知识也不迟。但入门阶段把精力花在这些上面，性价比极低。

3.3 我实际用到的工具链

说几个我实际在用的东西，不涉及任何敏感工具：

• 模型调用层：直接用各家提供的 API，前端用 fetch 或 axios 就能调，跟调普通接口没区别
• 编排框架：我用的是一个轻量的流程编排库，核心就是把多个步骤串成链，支持条件分支和重试
• 状态管理：复用了前端项目里的状态管理方案，把 Agent 的上下文当成全局状态来维护
• 调试工具：自己写了一个简单的日志面板，把每一步的输入输出都打出来，方便排查问题

提示：不要一上来就追求“全自动 Agent”，先从“半自动”开始——模型负责生成，人负责确认和触发下一步。这样出问题的概率低很多，也更容易调试。

4. 实操：从零搭一个最小可用的 Agent 流程

4.1 场景定义与任务拆解

我拿一个实际做过的内部工具举例：自动整理会议纪要并生成待办事项。这个场景足够简单，但包含了 Agent 开发的完整要素。

任务拆解下来是这样的：

1. 接收一段会议记录文本
2. 调用模型提取关键讨论点
3. 调用模型识别其中的待办事项和负责人
4. 把待办事项写入内部任务系统
5. 返回整理结果给用户确认

这里面第 2、3 步是模型调用，第 4 步是工具调用，第 1、5 步是前端交互。整个流程就是一个典型的 Agent 编排。

4.2 提示词设计的实操细节

我一开始的提示词写得很随意，比如“帮我提取会议里的待办事项”，结果模型经常把讨论内容也当成待办。后来改成结构化写法：

你是一个会议纪要整理助手。请从以下会议记录中提取待办事项。 要求： 1. 只提取明确有行动项的内容，纯讨论不算 2. 每条待办必须包含：事项描述、负责人、截止时间（如果没有则填“未指定”） 3. 输出格式为 JSON 数组，每个元素包含 description、owner、deadline 三个字段 4. 如果没有任何待办，返回空数组 会议记录： {{meeting_content}}

改完之后准确率明显提升。关键点在于：明确边界（什么算、什么不算）、明确格式（JSON 结构）、明确异常情况（没有待办怎么办）。这跟前端写接口文档的逻辑一模一样。

4.3 工具调用的参数设计

第 4 步写入任务系统，我设计了一个工具函数，入参就是模型输出的 JSON 数组。这里有个坑：模型输出的 JSON 偶尔会有格式问题，比如多一个逗号、少一个引号。我的处理方式是加一层校验和修复逻辑：

function safeParseJSON(text) { try { return JSON.parse(text); } catch (e) { // 尝试提取 JSON 部分 const match = text.match(/\[[\s\S]*\]/); if (match) { try { return JSON.parse(match[0]); } catch (e2) { return []; } } return []; } }

这个函数救了我很多次。模型输出不稳定是常态，前端做接口兼容的那套思路在这里完全适用。

4.4 流程编排与状态管理

整个流程我用一个状态机来管理，每个步骤是一个状态节点：

这个表是我实际写代码前先画出来的，画完之后代码结构就很清晰了。每个节点独立处理自己的输入输出和异常，节点之间通过状态传递数据。

4.5 实测效果与调优记录

第一版跑下来，待办提取的准确率大概在 70% 左右，主要问题是把一些“可以考虑”的内容也当成了待办。我做了两件事：一是在提示词里加了反例，明确说“讨论性语句不算待办”；二是加了一个确认环节，让用户在前端界面上勾选确认哪些是真正的待办。

加上确认环节之后，实际可用性大幅提升。这也印证了我前面说的：不要追求全自动，半自动的 Agent 反而更实用。模型负责生成候选，人负责最终决策，这个分工在现阶段是最稳的。

5. 踩过的坑与常见问题排查

5.1 模型输出格式不稳定怎么办

这是最高频的问题。我的经验是三层防护：第一层在提示词里明确格式要求并给示例；第二层在代码里做容错解析；第三层在流程上设计降级方案，比如解析失败就展示原始文本让用户手动处理。

不要指望模型 100% 按格式输出，就像不要指望用户 100% 按你预期的方式填表单。防御性编程的思路在这里是刚需。

5.2 多轮对话的上下文怎么管理

Agent 如果需要多轮交互，上下文会越来越长，成本和延迟都会上升。我的做法是：只保留最近 N 轮对话，更早的内容做摘要压缩。摘要本身也是调一次模型来生成，相当于把长上下文压缩成短上下文。

这个策略在前端做分页加载时也有类似思路——不是所有数据都一次性加载，而是按需加载加缓存。

5.3 工具调用失败怎么处理

工具调用失败分两种：一种是网络层面的失败，重试就行；另一种是业务层面的失败，比如参数不对、权限不够。我的处理方式是区分对待：网络失败自动重试最多两次，业务失败则把错误信息返回给模型，让模型决定是修正参数重试还是放弃。

这里有个细节：把错误信息返回给模型时，要用模型能理解的自然语言描述，而不是直接抛一个错误码。比如“任务系统返回：负责人字段不能为空”就比“Error 400”有用得多。

5.4 常见问题速查表

注意：排查 Agent 问题时，第一步永远是看日志。把每一步的输入输出都打出来，问题基本一目了然。我一开始偷懒没打日志，排查一个问题花了两个小时，后来加上日志之后，同样的问题五分钟就定位了。

6. 前端做 Agent 开发的边界与后续方向

6.1 哪些事该做，哪些事不该做

该做的：流程编排、提示词设计、工具接口封装、状态管理、异常处理、用户交互设计。这些是前端的主场，做起来顺手且有优势。

不该做的：模型训练、底层推理优化、算力调度。这些有专门的岗位负责，前端去碰性价比很低，除非你打算转型。

我个人的判断是，Agent 开发在未来一段时间内会成为前端的一个自然延伸方向，就像当年从写页面延伸到写 Node 服务一样。它不是要取代现有技能，而是在现有技能上叠加一层新的应用场景。

6.2 我后续打算深入的方向

一个是多 Agent 协作，就是多个 Agent 各司其职、互相配合完成复杂任务。这个在思路上跟微前端很像，都是把大系统拆成小模块、通过约定好的接口通信。

另一个是Agent 的可观测性，也就是怎么让整个流程对开发者透明、可调试、可追踪。这个方向前端有天然优势，因为前端一直在做类似的事情——把不可见的系统状态变成可见的界面。

6.3 给刚入门的朋友几句实在话

别被“大模型”三个字吓住。你不需要懂模型怎么训练，就像你不需要懂数据库怎么实现也能写 SQL。Agent 开发的核心是把不确定的能力组织成确定的流程，这件事前端每天都在做。

先从一个小场景开始，把完整流程跑通，再逐步加复杂度。我见过太多人一上来就想做“全能助手”，结果卡在第一步就放弃了。小步快跑，比什么都重要。

最后分享一个我自己的习惯：每次设计 Agent 流程时，先问自己一个问题——“如果模型每次输出都是错的，这个流程还能不能跑？”如果答案是能，那这个流程的健壮性就到位了。这个思路跟前端做异常兜底是一模一样的，只是换了个场景而已。