技术文章
前端接入Agentic AI的踩坑实录
早上8点，燕郊的家里。窗外没有北京西二旗那种让人窒息的早高峰喧嚣，只有楼下卖煎饼果子大妈的吆喝声。我喝了口保温杯里的温水，准时打开了电脑。
作为一个标准的小镇做题家，能留在北京拿着一份还过得去的薪水，我已经很知足了。虽然每天通勤1小时挤燕郊的公交和北京的地铁挺折腾，但最近公司搞“降本增效”，推行了混合办公，我每周有两天能在燕郊远程办公。不用通勤的日子，8点就能坐在书桌前干活，这效率简直比在公司摸鱼到10点再开工高太多了。
今天想聊聊最近被Leader逼着做的一次技术探索。本来以为是个轻松的活儿，结果差点没把我头发薅秃。主题就是现在火得一塌糊涂的Agentic AI，外加我们老本行前端。
PM的脑洞与我的噩梦
上周三下午，PM兴冲冲地跑过来，说竞品上了一个“超级智能助手”，不仅能聊天，还能帮用户自动查数据、生成图表、甚至直接操作后台。他大手一挥：“我们也要搞，而且前端交互必须丝滑，要有那种‘AI在思考’的极客感！”
我当时心里就咯噔一下。如果只是普通的LLM对话，搞个流式输出（SSE）就完事了。但他要的是Agentic AI（智能体）！这意味着AI不仅要“说”，还要“做”。它需要规划任务、调用外部工具（Function Calling）、处理中间状态，最后再把结果喂给前端。
作为团队里比较抠架构设计的人，我本能地排斥那种“先跑通再说，代码写成意大利面以后再重构”的搞法。于是，我顶着deadline的压力，决定好好设计一下前端的架构。结果，现实很快给我上了一课。
踩坑一：流式渲染把CPU干爆了
第一个坑来得猝不及防。为了体现“极客感”，我用了 react-markdown 来实时渲染AI吐出来的字。按理说这很常规，但Agentic AI在输出思考过程（Thought）时，语速极快，而且夹杂着大量的代码块和表格。
上周五晚上加班时，我本地一跑，好家伙，页面卡得像PPT。打开Chrome Performance一看，CPU直接飙到100%，一帧渲染要两百多毫秒。
原因分析：AI吐字是字符级别的流式，react-markdown 每次接收到新字符都会重新解析整段Markdown AST（抽象语法树）。当文本变长时，解析成本呈指数级上升。
填坑方案： 一开始我想着用 Web Worker 去跑解析，但通信成本太高。后来我换了个思路，做了“分块渲染”和“防抖”。
- 不要把每个字符都丢给Markdown组件。设置一个阈值，比如每接收50个字符，或者遇到换行符时，才触发一次渲染。
- 对于正在输出的“当前段落”，先用纯文本展示，等这段话输出完毕（遇到双换行），再将其替换为Markdown渲染后的结果。
// 核心逻辑伪代码
const handleStreamChunk = (chunk) => {
buffer += chunk;
// 如果包含完整的段落（以双换行结尾）
if (buffer.includes('\n\n')) {
const [completedPart, remaining] = buffer.split('\n\n');
setRenderedBlocks(prev => [...prev, parseMarkdown(completedPart)]);
buffer = remaining;
}
// 正在输出的部分用纯文本展示，避免频繁AST解析
setTypingText(buffer);
};
改完之后，页面瞬间丝滑了，当时真的长舒一口气，差点在办公室里喊出来。
踩坑二：状态管理写成了“屎山”
解决了渲染问题，更大的坑在状态管理。Agentic AI的执行流是非常复杂的：思考中 -> 决定调用工具 -> 工具执行中 -> 获取工具结果 -> 继续思考 -> 最终输出。
一开始，我习惯性地用一堆 useState 来管理：isThinking, isToolCalling, toolName, toolResult... 结果代码里全是 if-else，组件一更新，各种状态不同步，甚至出现了AI已经在输出最终结果了，前端还在转圈显示“正在调用工具”的弱智Bug。
看着这坨代码，我强迫症犯了。这根本不符合我追求的代码质量。AI生成的代码往往缺乏全局观，如果你不自己把控架构，最后绝对会变成屎山。
填坑方案： 我果断引入了状态机（State Machine）的概念。虽然项目里没上 XState 这种重库，但我自己手写了一个轻量级的状态机来管理 Agent 的生命周期。
| 状态 (State) | 触发事件 (Event) | 目标状态 (Next State) | 前端UI表现 |
|---|---|---|---|
Idle |
START_TASK |
Thinking |
输入框禁用，显示“思考中” |
Thinking |
TOOL_CALL |
Executing |
展示思考过程，显示工具卡片 |
Executing |
TOOL_RESULT |
Thinking |
工具卡片显示结果，继续思考 |
Thinking |
FINAL_OUTPUT |
Idle |
渲染最终Markdown结果 |
把状态流转收口到状态机后，组件只需要订阅当前状态，渲染对应的UI。代码清晰度直线上升，后来测试同学想加个“暂停执行”的功能，我只要加个状态和事件就搞定了，根本没动业务逻辑。
踩坑三：AI提效的“伪命题”
说到这，不得不吐槽一下现在满天飞的“AI提效”。
刚开始搞这个需求时，我为了赶进度，狂用 Cursor 和 Copilot。心想这帮大模型写个前端组件还不是分分钟的事？结果呢？它给我生成的状态管理代码，连个基本的类型推导都没有，甚至把 React 的 Hooks 规则按在地上摩擦（在条件语句里调 useEffect）。
我花了整整一个下午去给它擦屁股，修它产生的幻觉。那一刻我真的想砸电脑，这哪是AI提效，这是AI提血压！
心得体会： AI提效绝对不是无脑按 Tab。对于简单的 CRUD、正则表达式、或者写个单元测试，AI确实是神。但对于复杂的架构设计、状态流转、以及涉及业务上下文的代码，AI目前还是个“聪明的实习生”。
作为开发者，我们的核心竞争力正在从“怎么写代码”变成“怎么设计系统”和“怎么审查代码”。你必须比AI更懂架构，才能驾驭它，否则就会被它带进沟里。
总结与反思
这个需求上周终于上线了，PM看后直呼“牛逼”，说这交互体验吊打竞品。听着他的夸奖，我默默喝了口枸杞茶，深藏功与名。
回顾这一个多月的折腾，从被流式渲染卡成PPT，到用状态机重构屎山代码，再到对AI提效的祛魅。我最大的感触是：技术名词再怎么花里胡哨，底层的工程化思维和架构设计能力依然是王道。
Agentic AI 确实是个好东西，它把前端从单纯的“展示层”推向了“交互控制层”。但不管后端的大模型多聪明，前端作为离用户最近的一环，如何把复杂的黑盒过程透明化、优雅地展示出来，依然是我们前端工程师需要死磕的课题。
不说了，11点半了，该去楼下吃个隆江猪脚饭了。下午还得跟后端的兄弟对一下 Agent 工具调用的协议，希望他们别再偷偷改字段类型了，阿弥陀佛。
评论 0