Agent 智能体平台的前端架构怎么讲
如果面试官问我，假设从零设计一个 agent 智能体平台的前端架构，我会怎么做，我一般不会先讲组件库、状态管理选型，或者页面怎么切。我会先讲一个判断：这种系统前端本质上不是做一个聊天界面，也不只是做一个编排控制台，而是在做一个上下文工作台。
也就是说，前端要解决的不是“把消息展示出来”，而是怎么把 project、goal、task、card、session、trace、artifact、policy 这些对象组织成一个可操作、可观测、可治理的工作台。执行控制当然重要，但它是建立在上下文稳定之后的下一层能力。这个判断其实就是我在 Team AI 里最核心的经验。
如果按架构分层讲，我一般会拆五层。
第一层是工作台层，也就是用户真正看到的项目页、会话页、看板页、设置页、执行详情页。这一层重点不是页面数量，而是不同工作面之间要能切换得很自然。因为 agent 平台不会只有一个 chat 窗口，用户一定会在任务、会话、证据、历史和配置之间来回跳。所以前端从一开始就要按 workspace / project 上下文来设计，而不是按单页功能堆。
第二层是上下文 / 资源模型层。我会非常强调前端不能只围着接口返回值写页面，而是要先把核心对象抽象稳定。比如 Team AI 里至少有 project、goal、task、session、board、card、trace 这些对象。前端状态也最好围绕这些对象组织，而不是散成很多页面局部 state。因为 agent 平台天然是多视图共享同一份交付事实，如果对象模型不稳定，后面会越来越乱。
第三层是意图表达和状态同步层。这个层我会重点讲“用户意图”和“系统事实”要分开。比如用户拖一张卡片，不代表前端直接改成功了，而是前端发出一个 move intent，真正是否成功要等后端 policy 校验、workflow 执行和结果回写。所以这种平台我一般不会做成纯前端乐观更新，而是会让前端更像工作台：表达意图、展示中间态、等待 authoritative state 回流。Team AI 里这个回流就是通过 SSE 事件来做的。
第四层是实时证据和可观测层。因为 agent 平台如果没有实时状态，用户体验会非常差。你点了执行之后，如果只能看到一个 loading，其实系统就是黑盒。所以前端架构里我一定会把 SSE 或 WebSocket 当成核心能力，而不是附加能力。状态迁移、session 启动、trace 追加、artifact 生成、review 结果这些都应该是实时流进前端的。也就是说，这种平台的前端不是 request-response 驱动，而是 resource + event stream 双通道驱动。
第五层是扩展和治理层。agent 平台不会永远只有一种 provider、一个 specialist 或一套流程，所以前端要预留扩展点。比如 specialist 配置、provider 配置、workflow 模板、动作面板、不同执行阶段的展示组件，这些都应该尽量配置化或插件化。另外治理能力也要前置考虑，比如 WIP、entry rule、artifact gate、审批状态、审计轨迹，这些不是后端独有问题，前端必须把它们表达清楚，不然用户不知道系统为什么拒绝执行。
如果再收一层，我会说这种前端架构最核心的不是技术栈，而是三件事。
第一，上下文优先。前端必须先回答“系统里有哪些稳定对象，它们怎么组织”，而不是先回答“页面分几个 tab”。
第二，工作台思维。前端不是执行本身，而是让 AI 和人基于同一套对象、状态和证据继续协作的工作台。
第三，事件流优先。agent 平台天然是长链路异步系统，所以不能只靠接口请求驱动页面，必须把实时事件和最终状态回写纳入核心架构。
如果基于 Team AI 来讲，我会补一句更落地的话：我不会把它理解成“AI 聊天产品的前端”，而会理解成“AI 上下文工作台的前端”。所以我最先考虑的是资源模型、上下文壳层、实时状态回流和治理表达，而不是先做一个对话窗口。
如果面试官继续追问，我一般会顺着展开三个方向：第一，为什么 agent 平台前端不能只做 chat UI；第二，为什么对象模型和状态同步一定要先讲；第三，前端怎么把 policy、trace 和 artifact 这些治理信息表达清楚。
如果要对齐“Agent 平台前端”JD，建议补的点
1. 强调你做的是平台前端工作台，不是单页功能
我会明确说我做的是平台前端工作台和上下文界面，而不是某个聊天页或者某个任务列表。像 Team AI 里已经有项目工作台、Kanban、session 详情、trace 视图、workflow 页面这些工作面，这种表达会更贴近 Agent 平台岗位。
2. 把“任务调度、状态监控、执行日志”说成一条上下文链
不要分散讲成三个小功能，更好的说法是：前端同时承接任务入口、状态监控，以及 trace / workflow run / webhook log 这类执行痕迹可视化，让用户既能知道当前目标和上下文，也能持续看到执行过程。
3. 强调跨团队协作而不是单端实现
这个岗位会很看和后端、AI 工程师的协作，所以可以明确说：我不是只接接口，而是围绕 task、session、trace、事件流、资源契约一起定义前后端边界，确保工作台交互和后端执行链能对上。
4. 可以补组件化和壳层建设
如果岗位很看平台化，我会补一句：前端不是每个工作面各写一套，而是基于共享组件和工作台壳层去做复用。像 Team AI 里很多卡片、表单、导航、侧边详情都复用
@shared/ui，这会比只讲页面开发更像平台前端。
5. “多租户”不要硬说，改成项目级上下文隔离
这一点要特别注意。Team AI 当前更稳妥的证据是多项目 / project-scoped context，而不是标准多租户 SaaS。所以我会说我们围绕 projectId 做工作台上下文切换、资源隔离和视图展示，而不会直接写成完整多租户前端平台。
6. 文档和可维护性可以作为加分项补一句
如果岗位 JD 提到文档和可维护性，我会补一句：除了前端实现，我也会沉淀资源契约、架构说明和使用文档，并通过统一组件、资源模型和事件流边界控制复杂度，这样更像平台研发而不是功能开发。
30 秒版本
如果让我从零设计一个 agent 智能体平台的前端架构，我不会先讲聊天窗口怎么做，而会先把它定义成一个上下文工作台。前端核心不是展示消息，而是把 project、task、session、board、trace 这些对象组织成一个可操作、可观测、可治理的工作面。基于 Team AI 的经验，我会优先考虑统一对象模型、事件流驱动的状态回写，以及治理信息在前端的稳定表达。
1 分钟版本
我会先讲一个判断：agent 平台前端本质上不是 chat UI，而是上下文工作台。因为用户不会只看对话，他一定会在任务、会话、看板、执行结果、trace 和 artifact 之间来回切换。
所以前端架构上，我会优先拆三层。第一层是工作台层，负责项目页、看板页、会话页这些不同工作面；第二层是资源模型层，把 project、task、session、specialist 这些对象抽象稳定；第三层是状态同步和实时事件层，因为这种系统天然是长链路异步系统，不能只靠请求响应驱动页面，还要靠 SSE 或 WebSocket 持续回流系统状态。
如果结合 Team AI 来讲，我最关注的不是页面怎么搭，而是前端怎么把上下文组织清楚、怎么表达用户意图、怎么承接系统回写，以及怎么把 policy、trace、artifact 这些治理信息清楚展示出来。
3 分钟版本
如果让我从零设计一个 agent 智能体平台的前端架构，我会先把它理解成一个上下文工作台，而不是一个聊天应用。因为聊天只是一种交互入口，但真正的平台一定还会涉及项目上下文、任务推进、会话执行、证据沉淀和治理约束。
所以前端第一件事不是堆页面，而是先稳定对象模型。比如在 Team AI 里，我会先把 project、task、session、specialist、board、card、trace、artifact 这些对象抽出来，因为后面的看板、详情、执行页其实都在共享这些对象。如果对象模型一开始就不清楚，后面页面越多，状态会越乱。
第二件事是把用户意图和系统事实分开。比如用户拖卡片，不代表前端自己改成功了；前端表达的是 move intent，真正状态要等后端 policy 校验、workflow 执行和事件回写。所以这种系统我不会做成纯前端乐观更新，而会让前端更像工作台：先表达意图，再展示中间态，最后等 authoritative state 回流。
第三件事是实时事件流一定要是核心能力。agent 平台天然是异步长链路，用户很在意“现在执行到哪了”。所以前端不能只有 request-response，还要有 SSE 或 WebSocket 去接 session 启动、状态迁移、trace 追加、artifact 生成、review 结果这些事件。换句话说，页面不是一次次刷出来的，而是跟着系统执行过程持续长出来的。
第四件事是治理表达。agent 平台不是光能跑就行，还要让用户知道为什么能跑、为什么不能跑。像 WIP、entry rule、artifact gate、审批状态、provider 绑定这些东西，后端会做判断，但前端必须把这些判断结果表达清楚，不然用户只会觉得系统莫名其妙。
所以如果用一句话总结，我会说 agent 平台前端最核心的不是聊天体验，而是统一上下文模型、事件流驱动和治理可视化。这也是我基于 Team AI 得到的最直接经验。
高频追问
如果面试官追问“为什么你一直强调它不是 chat UI”
因为 chat 只是入口，不是平台本身。真正的平台还要承接任务、执行、回写、审计和治理。如果前端只按聊天产品设计，后面一旦要加看板、trace、artifact、审批和 specialist 配置，就会发现整个结构都不够用。所以我会从一开始就按工作台而不是按聊天页来设计。
如果面试官追问“前端为什么也要关心资源模型”
因为 agent 平台不是单页应用那种局部状态问题，而是多个工作面共享同一份交付事实。你今天在看板上看到的卡片，和会话详情页、trace 页、artifact 页，本质上都在看同一条执行链。如果前端不先把 project、task、session 这些对象抽象稳定，后面就只能在每个页面里重复拼数据，系统会越来越乱。
如果面试官追问“为什么状态同步一定要走事件流”
因为这种系统是典型的长链路异步系统。你点一次执行，背后可能会经历 session 启动、任务迁移、trace 追加、artifact 生成、review 回写。如果前端只能轮询或者只靠接口返回，体验会很差，系统也会像黑盒。事件流的价值，就是把过程持续暴露出来，让前端不是只看到结果，而是能跟着执行过程实时变化。
如果面试官追问“为什么不做纯前端乐观更新”
因为 agent 平台里很多动作不是前端自己说了算。比如卡片能不能移动，要不要审批，当前是不是超过 WIP，artifact 是否齐全，这些都要靠后端规则判断。前端如果太乐观，用户一开始会觉得快，但后面状态回滚会非常混乱。所以我会把前端定位成表达意图和展示中间态，而不是抢着宣布结果。
如果面试官追问“你觉得最核心的前端架构原则是什么”
我会收成三句。第一，围绕核心对象建模，不围绕页面临时拼装。第二，把前端当成上下文工作台，不当成纯展示层。第三，让实时事件和治理信息进入主架构，而不是后期补丁。这三句基本就是我基于 Team AI 总结出来的前端架构原则。
关联逐字稿
相关追问
一个很能说明这不是普通 chat UI 的细节
还有一个我很爱举的例子，就是页面壳层本身也是资源驱动的。比如项目页或者图页加载时，前端会带 Prefer: layout=sidebar, layout=breadcrumb 去拿当前资源。这个 Prefer 不是说让后端替前端排版，而是说：这次请求除了业务数据，也请把当前上下文下的导航信息一起带回来。
这样后端会顺手把 sidebar 和 breadcrumb 的 link / embedded 一起返回，前端壳层直接消费它们去渲染导航。换句话说，连左侧菜单和顶部面包屑都不是页面里写死的，而是跟着资源上下文走的。
我觉得这个例子很能说明为什么它不是普通 chat UI。普通聊天页一般只关心消息列表和输入框，但工作台型系统还要处理当前我在哪个项目、正在看哪个对象、还能去哪里、下一步能做什么。所以布局导航也进入了资源模型，而不是散落在每个页面里自己判断。
再补一个很能体现渐进增强的点：breadcrumb 不该等主内容
如果面试官继续追问前端壳层和主内容的边界，我会补一个细节：breadcrumb 不应该完全绑定到主内容数据请求完成之后才出现，因为它本质上是导航框架信息，不是主内容本身。
更合理的做法是分两层。
第一层，路由一切换，就立刻基于 pathname 渲染一个基础 breadcrumb。哪怕这个 breadcrumb 只是由 URL 片段拼出来的，它也能立即回答用户三个问题：我现在到了哪里、页面正在加载什么、我还能不能退回上一级。
第二层，等服务端资源把真正的 breadcrumb 返回后，再用业务命名去覆盖这个基础 breadcrumb。这样项目名、实体名会更准确，但导航框架本身不会因为主内容还没回来而整个消失。
这个细节其实很能体现 agent 工作台和普通页面的差别：工作台型系统更强调壳层稳定。sidebar、breadcrumb、返回路径这些框架信息，应该先给用户稳定反馈，再渐进增强成更准确的业务上下文，而不是和主内容一起阻塞、一起抖动。
如果我要把这句话收给面试官，我会说：在 Team AI 这种资源驱动工作台里，breadcrumb 最好是 shell-first 的渐进增强，先用路由上下文兜底，再用服务端返回的资源关系做业务级修正。