内容概览
这场演讲基于 Indeed 为 Claude、ChatGPT 和内部求职智能体 Career Scout 构建 MCP App 的实践，讨论如何避免“界面可见、模型失明”的常见失败。讲者指出，单纯在聊天中注入 HTML 或让组件自行调用现有 API，会把展示内容变成模型无法理解的黑箱，导致排序、总结、写求职信等后续任务失效。解决问题的第一步，是把界面展示的全部信息同步为结构化内容；第二步，是通过工具描述约束模型，避免它重复复述已经呈现的 UI；第三步，是把点击、展开详情等交互状态写回模型上下文。更关键的架构原则是将数据处理与 UI 渲染拆开：搜索工具可以被模型反复调用，用于跨城市检索、过滤和比较；独立渲染工具只接收最终选中的记录或引用。这样既保留智能体处理复杂任务的能力，也能生成具有品牌、操作按钮和模型解释的精炼界面。最终结论是：数据能力应当先于视觉组件，小而可组合的工具比绑定搜索与展示的单体工具更灵活。
更多内容
实践经验
从 Indeed 构建求职类 MCP App 的过程中提炼出的直接原则。
- 先定义模型需要访问和操作的数据，再设计界面；渲染应当是模型探索数据后的结果，而不是应用的起点。
- 任何显示给用户的信息都要同步提供给模型，新增字段时也必须同时更新结构化内容和界面。
- 工具描述应明确 UI 的展示行为，减少模型重复输出同一批信息。
- 点击、展开和选择等交互产生的新上下文，必须主动回传给模型。
- 用多个小型搜索与渲染工具支持组合式任务，比构建绑定所有能力的单体工具更有效。
深层洞察
由案例进一步推导出的产品与智能体设计含义。
- MCP App 实际上需要维护两套一致的可见性：用户通过组件看见状态，模型通过结构化数据和上下文更新理解状态。
- UI 与模型回复之间不是简单替代关系，而是一种动态分工：组件承担结构化呈现，模型承担筛选、解释和决策理由。
- 组件化展示可能意外成为智能体的停止信号；如果一次工具调用同时意味着“搜索并展示完成”，模型会减少后续探索。
- 独立渲染工具不仅解决展示问题，还提供了一个让模型把判断、推荐理由和重点标注注入产品体验的接口。
风险与陷阱
实现 MCP App 时容易导致模型失去上下文或任务能力的设计问题。
- 仅注入 HTML 或让组件自行请求 API，会形成模型不可见的数据黑箱。
- 搜索与 UI 渲染绑定后，模型可能只调用一次工具，无法完成跨条件、多轮检索和筛选。
- 未同步用户点击或展开状态，会使模型针对错误对象回答，甚至编造当前页面内容。
- 未说明结果已经由组件展示时，模型会重复生成文本版结果，造成冗余。
- 工具过大或描述过于复杂，会限制模型自由组合搜索、过滤和呈现方式。
技术实现要点
演讲中明确提及的 MCP App 接口、数据结构与工具拆分方式。
- 工具响应应同时包含 structured content 和 resource URI；前者供模型读取，后者指向应用 HTML。
- update model context 可向模型传递用户当前看到或操作的状态；MCP App 当前使用单个字符串，因此多事件需要累积追加。
- 职位案例拆分为无 UI 的 search jobs 工具，以及接收职位 ID 列表的 render jobs widget。
- 渲染工具的描述应规定数据来源、输入格式，以及调用渲染前必须先使用哪些数据工具。
- 渲染参数可从单纯的记录 ID 扩展为 ID、推荐理由和需要高亮的内容片段。