Agent 智能体平台前端架构反问与陷阱题

陷阱 1：这不就是聊天页面加几个侧边栏吗

我一般会直接纠正这个前提。聊天只是入口，不是平台本身。真正的平台还要承接 project、task、session、trace、artifact 和 policy 这些对象，以及它们之间的关系和状态流转，所以前端架构的核心不是聊天窗口，而是上下文工作台。

因为这种题里 Zustand、Redux、XState 只是手段，核心问题其实是对象模型和状态同步机制。如果 project、task、session 这些核心对象没抽稳，后面用什么库都会乱。所以我会先讲模型，再讲事件流，再讲具体实现手段。

因为 agent 平台里的很多动作不是前端自己说了算。卡片能不能移动、任务能不能执行、是不是缺 artifact、是不是触发审批，这些都需要后端规则判断。前端如果直接宣布成功，后面状态回滚会非常混乱，所以我更强调 intent 和 authoritative state 分离。

因为这些信息决定 AI 和用户能不能理解系统现在在干什么。平台如果只有结果没有过程，用户会觉得它像黑盒；AI 如果拿不到 evidence 和约束，也很容易漂。所以前端必须把规则判断、执行过程和证据沉淀表达清楚，不然再强的能力也很难被信任。

我会说因为这种系统天然是异步长链路。一次执行背后可能会经历 session 启动、状态迁移、trace 追加、artifact 生成和 review 回写。如果前端只靠接口请求驱动页面，用户会一直看到不透明的 loading。事件流的价值就是把过程持续暴露出来，让上下文是连续更新的。

我一般会用四件事证明。第一，有稳定对象模型；第二，有项目级上下文和壳层设计；第三，有前后端闭环的状态回流；第四，有治理能力和审计视角。只要这四件事成立，说明你讲的不是页面堆砌，而是一个真正的平台架构。

Agent 平台前端架构面试里最容易踩的坑，是把它讲成“复杂聊天 UI”或者“编排面板”。我会始终把它拉回到对象模型、上下文工作台、事件流和治理表达这四件事上。