这篇文章想讲什么

最近在补 Agent 项目时，我越来越强烈地感受到一件事：

很多前端做 AI 项目，最容易卡住的并不是“不会接模型”，而是太容易把项目停留在 Demo 阶段。

页面能聊天、工具能调用、流程能跑通，看起来已经像一个 Agent 项目了。
但只要面试官或者更有经验的工程师继续往下问几层，问题就会暴露出来：

  • 会话怎么管理
  • 数据怎么存
  • 工具失败怎么办
  • 多轮上下文怎么裁剪
  • 怎么判断系统真的比昨天更好

这些问题一旦答不上来，项目就很容易被判断成“只是一个能演示的样品”，而不是一个有工程价值的系统。

所以这篇文章不想从“后端必须怎么做”出发，而是想从前端视角总结：

  • 前端做 Agent 项目时，为什么也必须有系统思维
  • 为什么不能只停留在 UI 和框架调用
  • 为什么上下文工程和评测体系会决定项目到底像不像产品

一、前端做 Agent 项目，不能只停留在聊天框和工作流编排

很多前端做 Agent 项目时，最自然的切入点是：

  • 先做一个聊天框
  • 再接一个模型接口
  • 然后加工具调用
  • 最后补一点流程编排

这条路径没问题，但问题在于：很多项目做到这里就停了。

于是系统看起来像这样：

  • 用户输入
  • 模型返回
  • 有时候调用一个工具
  • 页面展示结果

如果只是自己学习，这种做法足够快。
但如果你想把它当成面试项目，或者希望它更接近真实系统，就不能只停在这一层。

因为企业环境下，Agent 本质上仍然是一个应用系统。
只不过这个系统的核心能力，不再只是传统表单和页面逻辑，而是多了一层模型推理和工具协作。

所以即使你是前端，也至少要能讲清这些部分：

  • 前端交互层：输入、状态展示、流式响应、错误态、回退逻辑
  • API 服务层：模型请求转发、权限控制、限流、工具路由
  • 数据层：会话、消息、任务记录、工具结果、评测结果
  • 日志和监控层：请求链路、错误原因、耗时、token 使用情况

前端不一定亲自把每一层都写完，但如果你完全讲不清这些层，面试官很容易得出一个结论：

  • 你做的是“能跑的 AI 页面”
  • 不是“具备上线思维的 Agent 项目”

前端为什么也要关心这些

因为前端不是只负责把结果画出来。

你在做 Agent 产品时，前端其实会直接碰到这些问题：

  • 如果工具调用失败，页面怎么回退
  • 如果响应流中断，消息状态怎么收口
  • 如果会话很多，上下文怎么分页、折叠或摘要
  • 如果模型输出不稳定，前端怎么做兜底展示

这些都说明：前端虽然不是系统的全部，但前端一定会被系统边界反向影响。

二、不要把“套了一个 Agent 框架”当成“做了 Agent 系统”

现在很多项目会接入一些 Agent 框架或者 workflow 能力，页面上也确实能看到：

  • 思考过程
  • 工具调用
  • 最终回答

但这并不自动等于“做了 Agent 系统”。

因为很多时候，本质仍然只是：

用户输入 -> 模型 -> 工具 -> 返回结果

这个流程当然有价值，但它更像是“单链路能力验证”，而不一定体现了系统设计能力。

什么叫真正的 Agent 系统能力

更成熟的 Agent 系统，通常至少会关注下面几件事：

  • 任务拆分：复杂请求是否会被拆成多个子任务
  • 路由决策：不同问题能否交给不同能力模块处理
  • 能力复用：工具和子流程是否能被反复复用
  • 调度控制：系统是否知道什么时候继续、什么时候停止、什么时候回退

这也是为什么很多人会开始研究：

  • 单智能体 workflow
  • Planner + Executor
  • Multi-Agent 架构
  • 专项 Agent 协作

但不是所有项目都必须做成多 Agent

这里要特别说清楚一件事：

不是所有好的项目都必须是多 Agent。

很多单链路任务里，单智能体 workflow 反而更好，原因很简单：

  • 链路更短
  • 结果更可控
  • 调试更容易
  • 成本更低

例如：

  • 剪辑类 Agent
  • 表单填充类 Agent
  • 特定知识问答 Agent
  • 单流程自动化任务

这些场景不一定需要复杂调度，强行上多 Agent 反而可能让系统更脆弱。

那为什么还要理解多 Agent

因为在面试和系统设计讨论里，多 Agent 不只是一个“功能更多”的方案，它更像一个能力证明：

  • 你是否理解任务拆分
  • 你是否理解调度中心
  • 你是否理解不同能力模块如何协作
  • 你是否能把复杂系统拆成多个职责清晰的部分

所以更稳的说法不是：

  • “我的项目一定要做成多 Agent 才高级”

而是：

  • “我知道什么时候单 Agent 更合适，也知道什么时候多 Agent 更能体现系统设计能力”

这句话比单纯追热点更有说服力。

三、上下文工程不是“保存聊天记录”这么简单

很多人刚开始做 Agent 时，对上下文的理解很朴素：

  • 把历史对话都存起来
  • 每次请求时再一起发给模型

这当然是最基础的做法，但复杂系统里，上下文工程远远不只是“保存历史消息”。

因为当系统变复杂后，你会立刻遇到下面这些问题：

  • 历史太长，token 成本越来越高
  • 无关信息太多，模型反而更容易答错
  • 不同任务不应该共享完全相同的上下文
  • 一些信息需要长期记忆，一些只需要短期存在

这时候你就会发现：

  • 上下文不是“聊天记录”
  • 上下文是“当前这次推理真正需要的信息集合”

前端为什么也要理解上下文工程

因为前端经常是上下文展示和交互的第一入口。

前端会参与这些问题：

  • 历史消息如何展示和折叠
  • 哪些工具结果应该露给用户，哪些只作为内部上下文
  • 用户是否能编辑、删除或固定某些记忆
  • 会话摘要、重要信息提取、知识片段引用怎么呈现

如果你只把上下文理解成“消息数组”，很多设计会做得很浅。

一个更像工程问题的理解方式

我更倾向把上下文拆成几类：

  • 当前任务上下文：这次请求直接需要的信息
  • 会话上下文：当前会话的历史与状态
  • 用户长期记忆：偏好、角色、常用设置
  • 工具运行上下文：工具返回的结构化中间结果
  • 知识上下文：检索召回的文档片段或业务知识

当你这样看时，就更容易理解为什么现在很多项目会单独研究：

  • Agent memory
  • context management
  • summary / compression
  • retrieval + rerank

这不是“锦上添花”，而是系统能否稳定工作的关键部分。

四、没有可观测性和评测体系，项目就很难持续优化

很多 AI 项目开发早期，大家判断效果的方式很直接：

  • 我自己问几个问题试试
  • 感觉回答还行
  • 工具也能调起来

这种方式在最开始验证方向时没问题。
但如果你想把项目讲成更像产品的系统，就不能长期依赖这种主观判断。

因为你很快会遇到这些问题：

  • 今天效果好，明天为什么突然变差
  • 是模型问题、工具问题，还是上下文问题
  • 哪一步耗时最长
  • 哪类问题最容易失败
  • 改完 prompt 或流程之后，真的更好了吗

如果没有可观测性和评测体系，这些问题都很难回答。

可观测性到底在看什么

至少可以追这些维度：

  • 一次请求走了哪些步骤
  • 每一步调用了哪个模型、哪个工具
  • 每一步耗时是多少
  • 哪一步失败了
  • 最终用了多少 token
  • 不同用户、不同会话的行为模式有什么差异

像 Langfuse 这类平台，很多团队会拿来做：

  • trace 记录
  • session 追踪
  • user 维度分析
  • prompt / response 对比

前端虽然不一定直接接这些平台，但前端会非常直接地依赖这些结果做判断。

比如：

  • 某一步慢，是不是应该在前端拆 loading
  • 某类任务经常失败，是不是要改交互引导
  • 某工具返回结构不稳定，是不是前端要加容错展示

评测体系为什么重要

因为“能运行”和“效果可靠”不是一回事。

很多项目在演示时能跑出一个看起来不错的答案，但这不代表系统真的成熟。
真正更像产品的做法，是给系统建立持续评测能力，例如：

  • 对固定样本集重复测试
  • 对输出结果做准确性、相关性评分
  • 记录不同版本之间的效果变化
  • 结合人工标注做回归分析

这样你才能回答面试官更喜欢问的那类问题：

  • 你怎么证明这个版本比上一个版本更好
  • 你怎么定位系统效果退化的原因
  • 你优化的到底是“感觉”，还是可验证指标

五、如果你是前端，面试里应该怎么讲这些点

很多前端在讲 AI 项目时，容易把重点放在：

  • 我用了什么模型
  • 我做了什么 UI
  • 我接了哪些工具

这些当然要讲，但如果想显得更像做过系统的人，可以把顺序换一下：

1. 先讲完整闭环

不要上来就讲聊天框。
先讲这套系统怎么跑通：

  • 用户请求从哪里进入
  • 怎么流到 API 层
  • 怎么走模型和工具
  • 结果怎么存
  • 错误怎么回退

2. 再讲你负责的前端部分

例如：

  • 流式状态机怎么设计
  • 工具调用结果怎么展示
  • 会话和上下文如何在界面中组织
  • 错误态、取消态、重试怎么处理

3. 再补系统理解

哪怕你没有把后端全写完，也要能清楚说出：

  • 如果要上线，这个项目还缺哪些层
  • 哪些问题目前只是 Demo 级方案
  • 哪些能力需要后端、数据库和监控平台配合

面试官通常并不要求前端把所有东西都自己实现，但他很在意你有没有这个视角。

4. 最后讲取舍

这是很容易加分的一步。

比如你可以这样讲：

  • 为什么这个场景先选单 Agent，而不是多 Agent
  • 为什么先做最小上下文管理，而不是一开始就做复杂记忆系统
  • 为什么先补 trace 和日志，而不是盲目调 prompt

这种“知道先做什么、不做什么”的表达，通常比堆一堆名词更有说服力。

六、现在更看重的，不是功能多，而是系统像不像真的能长大

做 Agent 项目一开始，大家都会天然被“模型能力”吸引。
但往后走得越多，越会发现一个现实：

  • 真正决定项目上限的，往往不是你接了几个模型
  • 而是你有没有把它当成一个系统来做

对前端来说，这个认知尤其重要。

因为前端最容易做出“看起来很完整”的 Demo：界面漂亮、对话顺畅、流程也能跑。
但如果没有系统视角，项目很容易在真实复杂度面前失去稳定性。

所以我现在更愿意用下面几个问题来反问自己：

  • 这个项目如果用户量上来，会不会立刻失控
  • 这个项目如果工具失败，能不能优雅回退
  • 这个项目如果上下文越来越长，还能不能保持效果
  • 这个项目如果我一个月后回来，还能不能继续定位和优化

如果这些问题都还回答不了，那它就更像一个很好的 Demo。
如果这些问题开始有了清晰答案，它才更像一个真正有成长空间的 Agent 系统。

参考启发

下面这篇文章给了我很强的启发，但我在这里做的是“前端视角的再理解”，不是直接照搬原文：

总结

前端做 Agent 项目，不应该只把自己理解成“模型结果的展示层”。

更好的做法是：

  • UI 要做好
  • 交互要稳定
  • 但同时也要能讲清系统闭环、上下文工程、调度能力和评测体系

因为真正让一个 Agent 项目从 Demo 走向产品的，往往不是多写几个功能，而是开始用系统的眼光看它。