Agent 智能体平台前端岗位逐字稿
使用方式
- 适合岗位 JD 强调：Agent、任务调度、状态监控、执行日志、组件库、平台化协作。
- 这版口径默认基于 Team AI 项目逐字稿，但会把重点收敛到“上下文工作台前端”而不是“纯编排控制台”。
- 如果要同步改简历，直接配合 全栈工程师简历成品版（可直接改） > Team AI 一起使用。
- 如果面试官继续追问架构，切到 Agent 智能体平台的前端架构怎么讲；如果开始压力面，切到 Agent 智能体平台前端架构反问与陷阱题。
一句话定位
如果让我一句话概括，我会说：我做的不是普通聊天页，也不只是编排控制台，而是一个把项目上下文稳定组织给 AI 和人共同消费的前端工作台，执行控制只是建立在这套上下文之上的能力。
面试逐字稿
1. 自我介绍
面试官： 你先做一下自我介绍，重点讲和这个岗位相关的部分。
候选人： 您好，我目前更偏平台型前端和全栈协作方向。过去一段时间我重点做的项目是 Team AI，它不是单纯的 AI 聊天产品，而是一个面向软件交付场景的 AI 上下文工作台。我的工作重点主要有三块：第一是把 project、card、conversation、trace 这些核心对象组织成稳定的前端工作面，比如项目页、Kanban、会话页和详情页；第二是围绕资源契约、状态回流和实时事件，把前端和后端串成一条一致的上下文链路；第三是做平台化能力，包括共享组件、工作台壳层、资源模型和可维护性治理。所以如果对应这个岗位，我比较匹配的点不是只会做页面，而是做过 Agent 平台前端工作台，并且参与过对象建模、状态同步和交互边界的一整条链路。
2. 你如何理解 Agent 平台前端的核心价值
面试官： 你怎么理解这种 Agent 平台前端的核心价值？
候选人： 我会把它理解成一个上下文工作台，而不是消息展示层。因为用户关心的不是“AI 回了什么”这么简单，而是当前目标是什么、任务处在哪个阶段、为什么会卡住、下一步能做什么、历史上发生过什么。也就是说，前端真正要做的是把复杂系统里的对象、关系、证据和状态用低认知成本表达出来，让用户和 AI 都能基于同一套上下文继续往下推进。
3. 如果结合 Team AI，你们的 Agent 前端是怎么落地的
面试官： 如果结合你做过的项目，Agent 平台前端是怎么落地的？
候选人： 在 Team AI 里，我不会先从“几个 agent 怎么编排”开始讲，而会先从上下文怎么被结构化开始讲。一个需求先通过 intake 进入系统，沉淀成 spec、task、card 这些稳定对象，再同步到看板、会话和 trace 视图里。Kanban 的列本身也不是纯展示状态，而是在表达当前阶段允许什么动作、缺什么 evidence、是否需要 review。也就是说，前端先把目标变成可消费上下文，再承接后面的 specialist 路由、workflow 执行和状态回写。所以执行是有的，但它是建立在稳定上下文上的次级能力，而不是项目主轴。
4. 任务调度、Agent 状态监控和执行日志前端怎么做
面试官： 这个岗位会做任务调度、状态监控和执行日志，你会怎么设计？
候选人： 我一般会拆成“快照 + 事件流”两层。页面首次进入先拉当前 card、session、workflow run、trace 和相关 evidence，保证首屏能把当前上下文讲清楚；后续再通过 SSE 或 WebSocket 订阅状态变化和新增日志。这样一来，用户既能看到当前全貌，也能持续看到过程变化。日志页我会重点处理三个问题：第一是增量追加和断线重连；第二是大量日志的性能，比如虚拟列表、分块渲染、关键词检索；第三是日志和执行阶段联动，让用户能从某个 session、某次状态迁移快速定位对应 trace。这样日志就不是一坨文本，而是上下文证据的一部分。
5. 你如何和后端团队、AI 工程师协作
面试官： 这种平台前后端协作很重，你一般怎么配合？
候选人： 我会把协作重点放在契约前置。比如 card 代表什么、session 生命周期怎么定义、trace 结构长什么样、失败类型怎么归类、事件 payload 里最小必需字段是什么，这些都要在联调前先定义清楚，不然后面前端很容易写一堆临时兼容。和 AI 工程师协作时，我也会特别关注“上下文是不是连续的”，因为 AI 结果往往不是一次性返回的，而是分阶段、流式甚至不完全稳定的，所以前端必须配合设计处理中状态、步骤反馈、错误说明和证据回看，而不是只等一个最终结果。
6. 这个岗位提到多租户，你会怎么答得既稳又真实
面试官： JD 里提到多租户前端数据隔离，你会怎么做？
候选人： 如果完全按我做过的 Team AI 经验来讲，我会更稳妥地先讲 workspace / project scope 的上下文隔离，因为这是我真实做过、证据最强的部分。具体做法是把上下文放到路由、全局资源模型和请求层里，切换项目或工作区时同步清理缓存、重置状态，并且让列表、详情、导航和筛选都处在同一个上下文下。再往多租户扩展，本质上也是一样的思路，只是从 project-scope 扩大到 tenant-scope：路由明确租户、请求显式带租户、缓存按租户切分、展示上持续提醒当前上下文，避免串数据和误操作。
7. 组件库和平台可维护性你会怎么建设
面试官： 组件库和可维护性这块你会怎么推进？
候选人： 我会按三层做。第一层是 Button、Input、Dialog、Table 这类基础组件；第二层是卡片状态、trace 列表、evidence 面板、步骤条这类业务增强组件；第三层是工作台级组合模式，比如左侧导航 + 主内容 + 右侧详情面板这种壳层结构。这样做的价值是，前端不是每个页面都从头写，而是围绕稳定对象和稳定交互模式复用。同时我会配合类型约束、文档、示例和测试，把可维护性前置，而不是等页面越来越多以后再返工。
8. 如果页面卡，尤其是任务列表和日志页卡，你怎么排查
面试官： 如果任务列表或者日志页很卡，你怎么优化？
候选人： 我不会先拍脑袋优化，而是先区分瓶颈是在请求、计算还是渲染。任务列表常见问题是筛选排序重复计算、状态更新过于频繁、列表一次性渲染过多；日志页常见问题是高频 append、自动滚动、富文本渲染叠加。我会优先做虚拟列表、批量更新、减少无效重渲染、快照和增量分离，以及断线重连后的幂等合并。对 Agent 平台来说，性能优化的关键不是某个动画卡不卡，而是上下文很重、事件很多时，页面还能不能持续稳定地承接系统变化。
9. 你为什么适合这个岗位
面试官： 你觉得你为什么适合这个岗位？
候选人： 我觉得主要有三点。第一，我做过的平台前端不是传统后台，而是面向 AI 和人共同协作的上下文工作台，这和岗位方向很贴近。第二，我不只关注 UI，本身也参与对象建模、资源契约、状态回流和日志可观测性设计，所以更容易把复杂系统做成闭环。第三，我比较习惯从平台角度看问题，会主动把组件复用、资源模型、性能和维护成本放到设计里，而不是等需求压上来再被动修补。
10. 反问环节
面试官： 你有什么想问我们的？
候选人： 我一般会问三个问题。第一，目前这个平台前端最大的挑战是复杂交互、实时状态，还是上下文建模和对象边界？第二，任务、会话、trace 和日志这几类核心对象，现在前后端契约是否已经相对稳定？第三，团队对这个岗位的期待更偏业务交付，还是也希望前端同学参与组件库、架构和平台规范建设？这三个问题能帮助我判断入职后应该先补业务闭环，还是先补平台基础设施。
可以直接背的收口句
我比较适合这个岗位的原因，是我做过的不是单页功能，而是 Agent 平台前端工作台；我关注的不只是 UI 本身，还包括上下文建模、状态回流、日志可观测性和平台治理边界。