Cursor客户端解剖（五）Chat、Composer-与-Agent

发表于 2026-08-03 分类于 Cursor

系列：Cursor客户端解剖系列学习笔记
上一篇：（四）Agent三件套

意图入口在 Workbench，不在第三方插件

能力流第一站是：

Composer / Glass —— 聊天与任务是工作台能力

包内能看到：

contrib/composer、services/ai、services/agentData 一类 workbench 增量
双入口 bundle：workbench.desktop.main.js 与 workbench.glass.main.js
Glass 目录下还有特效 worker、品牌媒体、启动视觉；Workbench 亦带 react-runtime/，部分新 UI 用 React 嵌入经典壳

设计含义：

UI 可换壳，服务尽量共用。
大产品做 UX 跃迁时，双轨并存比一夜重写更工程。

Chat / Composer / Agent：产品名会变，模式门闩更重要

对外名称常变，包内 prompt / 协议里更稳定的是模式：

模式信号	系统侧在强调什么
Ask	不能跑非只读工具
Agent / IDE coding agent	在用户机器上作为 coding agent 运行，用工具查，不要猜
Debug	要运行时证据，专项调试人格
Cloud / Background	更自主；执行环境可能在云 VM
Orchestrator	编排者倾向委派，用 Task/子代理，而不是自己改所有文件

还有 SwitchModeToolCall：模式切换本身可以是工具调用——说明模式是运行时状态机，不是单纯 UI Tab。

子 Agent：人格化工具子集

协议里能看到专门子代理类型，例如：

Explore · Shell · BrowserUse · ComputerUse · Debug · CursorGuide · …

父 Agent 通过 TaskToolCall 派生子任务。各自带不同 system 片段与工具子集——这是「编排 / 执行」在产品层的再一次拆分：不是一个全能循环死磕到底，而是可委派。

本地先收积木，服务端再拼终态 prompt

你在 Chat/Agent 输入框提交后，Workbench 先收集（不跑大模型）：

模式、模型选择、选中上下文、附件
Rules / Skills / MCP 工具清单 / 检索元数据
user_info、打开文件、选区、git 状态等

然后发出流式 AgentRunRequest（字段包括 conversation_state、model_details、mcp_tools、custom_system_prompt、skill_options…）。

最终 system/user prompt 主要在服务端（aiserver）拼好并调用模型。
客户端负责积木与执行面；这解释了为什么「完整 prompt 抓包全文」在应用包里看不到，但协议字段足够还原设计逻辑。

和执行链的衔接

Glass / Classic UI
    → 收集意图与上下文积木
    → AgentRunRequest（流式）
    → aiserver：拼 prompt + 调模型
    → interaction_update（text / thinking / ToolCall）
    → agent-exec 执行
    → 结果回传 → 循环

UI 的职责是：收得全、展得清、批得动（diff、todo、提问、计划）。
真正危险的副作用不在 UI 进程里随便发生。

小结

Chat / Composer / Agent 在包内更准确的读法是：

意图入口属于 Workbench/Glass 一等公民
模式门闩改变工具可用面与 system 片段
子 Agent 是委派机制，不是换肤
双 UI 轨是演进策略，不是重复造轮子

下一篇进入工具循环：强类型 ToolCall、MCP、Rules/Skills、权限契约。