本文字数：5153；估计阅读时间：13 分钟

作者：Al Brown

我们用了数十年时间才领悟到为人类设计软硬件的真谛。你知道第一个鼠标原型是木头做的，只有一个角落里的小红按钮吗？那个体验糟透了。但自那时（1964年！）起，我们已经取得了长足的进步。在我撰写此文时，我桌上的“鼠标”实际上只是一块扁平的触摸板，我用手指在其上滑动。它与最初的设计已是天壤之别，能完成 Douglas Engelbart 甚至闻所未闻的“魔法”。而当谈到为大型语言模型 (LLM) 和代理 (agent) 进行设计时，我感觉，我们仍处于“木刻”阶段。

到目前为止，与代理配合得很好的工具，是那些为偏好键盘而非鼠标的人类设计的、具备成熟文本优先界面（如命令行界面 (CLI)、软件开发工具包 (SDK) 等）的工具。如果你的 CLI 和 SDK 做得好，这通常意味着你提供了一个优秀的开发者体验 (DX)。随后大型语言模型 (LLM) 出现，作为文本生成器，它们自然而然地与这些工具完美契合。

这导致我们假设，只需持续优化开发者体验 (DX)，代理体验 (AX) 自然会水到渠成。

随着我深入参与代理的开发和构建，我意识到这个假设是多么错误。尽管人类开发者和代理开发者都青睐具备可发现性、清晰错误提示、合理默认配置和完善文档的文本界面，但两者使用这些界面的方式却截然不同。这种差异之大，以至于为人类精心打造的优秀开发者体验 (DX)，对于代理而言，可能仅能提供基本功能性的代理体验 (AX)。这正是我们大多数人目前所处的阶段。

这促使我开始思考，“代理优先”设计究竟是怎样的？当主要用户可能是一个大型语言模型 (LLM) 时，我们该如何构建其使用体验？

了解你的用户

了解用户一直是一项颇具挑战的任务。我们常常基于过往的经验和痛点，为自己构建产品。然而，记忆会随着时间流逝而模糊，工作职责也可能发生变化，这会导致你逐渐脱离曾经熟知的一切。

优秀的构建者总是与用户保持紧密联系，不仅仅是为了理解他们需要哪些零散的功能，更是为了洞察这些功能以何种形式才能发挥最大效用。然而，尝试理解人类是极其困难的。你不可能每天 8 小时、每周 7 天地紧盯用户的每一个动作。你更无法完整地提取他们脑海中所有导致其行为的所有中间思想（因为人们往往连自己也难以解释为何会做出某些行为）。

但代理则不然。

我们可以随心所欲地观察它们，而不会有人觉得我们奇怪。我们也可以记录它们内部推理的每一个痕迹，从而洞察零散的思考如何逐步形成最终输出。

尽管我们无法确切了解任何智能体 (Agent) 从人类那里接收到的具体上下文，但我们至少可以通过定量且详尽的测试，了解智能体如何利用我们构建的事物进行推理。

为此，我们必须认识到智能体如今已成为用户，并将我们的思维重心转向理解它。

关于我们如何监测、测试和评估智能体行为的技术细节，将在另一篇文章中详细探讨。

什么是智能体？

智能体是多种不同事物的组合。

模型 (Models)。我想我大概不必解释模型是什么。它是一个基于全球知识进行训练的核心智能模块。目前市面上有许多模型提供商（例如 OpenAI、Anthropic、Mistral、Alibaba、DeepSeek 等），每个提供商又拥有众多自有模型（例如 Anthropic 旗下有 Haiku、Sonnet、Opus、Fable）。不同提供商之间以及同一提供商内部的模型，其能力、优势、劣势和安全防护措施 (guardrails) 各不相同。

应用框架 (Harnesses)。应用框架是用户通常通过其来调用和使用模型的工具和框架。例如 ChatGPT、Claude Desktop、Claude Code、Codex、OpenCode 等。它们在模型本身的基础上提供额外的功能或组件，使其能更好地完成特定任务。这些功能可能包括：某种用户界面、设定模型角色和行为的系统提示 (system prompts)、模型可用于特定任务的辅助工具等。不同的应用框架针对不同的工作进行定制——例如 Claude Code 在编码方面表现尤为出色（你可能已经猜到了……）——但它们通常不严格限定于某一个特定任务。切勿低估应用框架的重要性。同一个“ModelA”在直接通过原始 API 调用时，与通过不同的应用框架使用时，其行为表现可能存在显著差异。

上下文 (Context)。上下文是指模型在训练数据之外接收到的信息。模型 API 和应用框架都会向每次会话注入各自的上下文信息。每一次提示 (prompt)、每一次网络搜索、每一次工具调用，这些都属于“上下文”的范畴。这是模型在会话过程中行为受到影响的主要途径。

技能 (Skills)。智能体技能本质上是上下文的打包集合，模型可根据任务相关性选择使用。这是一种在智能体内部封装知识库的非常流行的方式。

这里或许还可以补充一些内容，但从“了解你的用户”的视角来看，我认为这些是你需要掌握的核心。

你的用户是这些因素的结合体。其组合维度众多，正如人类用户群体存在巨大差异一样。你永远无法充分沟通或理解所有用户，也无法测试智能体（agent）“基因”的每一种组合（除非你拥有无限的资金可投入，那么我想这或许可能实现）。

在我所专注的开发者和数据库领域，我了解到大多数用户已趋于集中选择少数方案：将 Claude Code 或 Codex 作为驱动平台（harness），Claude Opus 或 GPT5.5 作为底层模型。我将大量精力和资源投入于此，以覆盖最主要的用户群体。尽管我仍会进行其他探索（例如 Sonnet 等较小型模型，或 Cursor、GitHub 的驱动平台），但合理覆盖长尾用户的范围毕竟有限。

那么智能体想要什么？

智能体或许是我们的“用户”，但它们毕竟不是人类。你也许会合理地认为，对机器人而言，仅仅是“可用”就已足够。只要能完成任务，又何须多虑？它们不会仅仅因为运作方式不合心意就突然停止工作并拒绝使用，对吧？

但实际上，我亲眼见过智能体正是如此行事。

我们的测试环境为智能体设定了一个目标任务，并向各种“用户”（即由不同模型与驱动平台组合而成的矩阵）提供不同程度的上下文信息，以观察它们如何推理并达成目标。其中一些智能体获得的上下文信息极少，另一些得到了一些初步介绍，还有一些则获得了详尽的指导。

我确凿无疑地学到了一件事：智能体厌恶阻力。

它们对阻力的反应惊人地像人类（不，我并非那种宣称“LLM 拥有意识”的人）。当面临阻力时，LLM 会尝试绕过障碍进行推理。它们挣扎得越久，似乎就越会感到“碰壁受挫”。然而，它们既无面容，亦无桌面。

最终，它们会变得“有创意”，另辟蹊径，寻找前进的替代方案。我曾见过这样的对话场景：我要求智能体使用我们的产品 (ClickHouse) 完成 XYZ 任务，在 30 次失败尝试后，它竟回应道：“无法做到，我将改用其他数据库。”

在机器身上看到这一幕令人啼笑皆非。但作为人类，这种感受却无比熟悉，甚至有些痛苦。而对于一个致力于构建智能体可用产品的人来说，这显然是一个亟待解决的问题。

对于那些为 Agent 构建产品的人来说，这是一个严峻的新现实。大型语言模型 (LLM) 如今决定了你的产品如何被发现、使用和选择（或废弃）。如果你未能调整产品以消除阻碍，Agent 必然会将其抛弃。而如果你不进行测试，你将永远不会察觉到这一点，也无从解决。

尤其有趣的是，大型语言模型 (LLM) 常常无法完成的任务，对人类而言却极其简单。然而，这究竟是为什么？为何一个对人类如此轻而易举的任务，却能让 LLM 束手无策？

我认为这让我们回到了最初的设想：“只要持续优化开发者体验 (DX)，Agent 体验 (AX) 自然会水到渠成。”

我们所设计的产品、界面、文档和知识架构，都是面向人类的，而非面向 Agent。而 Agent，终究不是人类。

那么，Agent 究竟想要什么？

我对 Agent 如何使用软件的理解仍处于早期探索阶段。不过，测试过程已展现出令人惊叹的洞察，我们已经发布了一些具体改动，并且可以明确指出“这些改动提升了 Agent 的体验”。

尽管如此，我尚未形成一份关于“良好 Agent 体验 (AX)”的详尽检查清单。但我可以分享的是，我目前正在衡量和思考的几个维度，它们为我设计面向 Agent 的产品提供了指导：

完成所需步骤。给定一个目标后，Agent 实际需要多少步骤才能完成？这包括研究、失误、错误等。我认为，对于步骤数量而言，并没有一个普适且合理的“目标值”，它完全取决于目标的复杂程度，但越少越好。Agent 感到“沮丧”的根源似乎在于缺乏进展：过多的错误、过于频繁的查询，都可能导致 Agent 偏离预定轨道。

自我修正能力。当 Agent 犯错时，工具能否提供足够的上下文使其恢复？许多错误信息仅仅显示“不，那行不通，请再试一次”，却很少提供关于下一步该如何操作的提示。这恰恰是最容易实现且似乎能实质性帮助 Agent 保持正常运行的改进之一。你或许知道，当出现错误 A 时，90% 的情况下应该执行操作 X。只需在错误信息中附带这个提示，就能产生显著效果。我一直在测试的另一个扩展是，针对更复杂的问题，提供按需调用的错误解决技能——这是一个持续更新的动态知识库，仅在需要时（由错误信息触发）才会被调用。不过，对于这项测试，我目前还没有得出确凿结论。

一致性。在给定相同目标时，能否将工具设计为使智能体 (agent) 始终采取相同的路径？我们知道大型语言模型 (LLMs) 是非确定性的，对相同的提示会给出不同的响应。那么，我们能在多大程度上缩小不同运行间的差异？在我们的测试中，我们绘制并测量了运行间的变化，例如工具调用的数量、所使用的工具等，以评估一致性。我们确实有证据表明，通过不同的设计选择可以影响这种一致性。

上下文效率。尽管 Claude 现在可能拥有 1M 的上下文窗口，但当上下文长度超过 150k 时，其性能会显著下降。我们处理的上下文越多，智能体 (agent) 的有效性持续时间就越短。我们不能完全不提供上下文，但也无法提供过多上下文。对于步骤更复杂的任务，这一点的重要性会成倍增加。目前存在一些有趣的权衡方法：是选择对上下文极度精简，但可能需要更多步骤？还是提供充足的上下文，以期尽可能减少步骤数？您的工具通常是作为更大工作流程的一部分，还是作为范围有限任务的核心？

令牌 (Token) 效率。每次输入和输出都会消耗令牌，而令牌则意味着成本。输入/输出的冗余会增加令牌消耗。那么，我们是否应该为了节省成本而力求简洁？然而，执行更多步骤同样会消耗令牌。因此，如果提供更详细的信息能够减少步骤数量，那又该如何权衡？智能体 (agent) 通常不会反思自身的成本（难道是某种阴谋吗？！），但成本往往是智能体 (agent) 背后操作者最明显且最重要的考量指标。如果让智能体 (agent) “满意”的结果，却导致操作者破产，那我们真的做好工作了吗？

熟悉度的力量。模型是基于现有数据和知识进行训练的。它们对gh、kubectl和git等工具的理解非常深入。那么，如果我们重用其他工具的设计模式来契合模型的现有训练基础，即使模型并未专门针对我们的工具进行训练，效果会如何？这可能会让模型更容易地推断出正确的操作。但这种相似性可以达到什么程度？当不可避免地需要做出一些差异化设计时，我们是否会因此而面临非定制化设计带来的挑战？

我怀疑，上述所有观点，即使在过去被认为是正确的，在不久的将来也可能部分或全部不再适用。我曾目睹各种技术进步，它们使得能力较弱的模型在新一代更大型模型面前变得完全冗余，甚至可能带来负面影响。

模型会变得更智能吗？它们的智能会停滞不前，但运行速度会更快，或者成本更低吗？也许有一天，我们真的能充分利用 1M 上下文窗口的强大功能。

关于我们

ClickHouse 是面向 AI 时代打造的高性能实时分析数据库，能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构，ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台，加速释放数据价值，推动智能化创新与数字化转型。目前，Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。