Agent 三人群聊模型

Agent As Three Way Group Chat · agent-as-three-way-group-chat--raviv-khan

解决什么问题

评估"我们的 agent 能不能做 X"时没有第一性框架；被 tool calling、MCP、agent harness 这些术语唬住，无法参与技术讨论。

核心内容

LLM 只能产出文本。任何"行动"（改文件、抓数据、搜网页）都是在调用工具（tool call）。
三方群聊模型：经典 ChatGPT 是 LLM 与人的私聊（DM）；AI agent 则是 LLM、人、工具三方的群聊。
LLM 自己不能执行命令，要靠 harness（如 Cursor）代劳：LLM 打出工具名和参数描述想做的事，harness 在你电脑上执行该工具，把结果（成功输出或报错）返回给 LLM 决定下一步。类比：LLM 是描述需求但拿不了锤子的人，harness 是听懂需求、动手干活、汇报结果的 handyman。"MCP client"和"agent harness"说的都是这个角色。
Tool calling 是独立的能力维度，与推理、写作质量分开。不是"最聪明的模型赢"：同一编辑任务 Gemini 用 3 次 tool call、Opus 用 2 次；OpenAI 模型曾在 Cursor 的 apply_patch 工具上频繁失手，尽管其推理没问题。coding agent 的大部分工作靠一小组文件导航/文本编辑工具完成。
判断句式：有人问"我们的 agent 能做 X 吗？"→ 条件反射地反问"它需要哪些工具？我们的模型调用这些工具有多稳？"
MCP 祛魅：企业最有价值的数据在外部 SaaS（Linear、Figma、Notion、Snowflake、Amplitude 等）里，这些服务需要给 LLM 提供自定义工具。为避免每家 SaaS 对接每个 LLM 的 N×M 混乱，行业采用了 Model Context Protocol 标准——每家只建一个连接器即可到处能用。类比 USB/蓝牙；且"多数 agent 工具不是 MCP，就像多数电线不是 USB 头"——MCP 只是接口标准化了的又一种工具。

适用边界

该模型解释单 agent 的行动机制；subagent（另开一个线程处理子任务、只回传结论）是相关但不同的概念。
模型间 tool calling 行为差异随版本演进变化（原文注明较新的 Codex 模型已改善），具体结论需重测，判断框架不变。

关键引述 · 原话

Tal Raviv & Aman Khan: "If we view 'classic ChatGPT' as a DM thread between an LLM and a human, then AI agents are a three-way group chat between an LLM, a human, and tools."

Tal Raviv & Aman Khan: "It's not just 'smartest model wins.' Tool calling is its own behavior, separate from reasoning or writing quality."

— Tal Raviv & Aman Khan

关联卡片

上下文工程与退化 Agent 三层栈架构 AI 自主权与控制权衡

- 同源卡：`context-engineering-and-context-rot--raviv-khan`（tool 定义同样消耗 context window）。 - 呼应 `agent-stack-model-api-harness--alexander-embiricos`（model/API/harness 分层）；`agency-control-tradeoff--reganti-badam`（agent 的行动能力即 agency 的来源）。

出处：Tal Raviv & Aman Khan (AI 产品人，Build AI Product Sense 工作坊创办者) · 02-newsletters/how-to-build-ai-product-sense.md
提炼自 Lenny Rachitsky 的 Lenny’s Newsletter & Podcast（2019–2026）。本站为个人学习用途的二次创作，与 Lenny’s Newsletter 无官方关联。
provenance · 已核验 · glm-5.2