本文字数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 作为驱动平台harnessClaude 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 支撑其关键业务和数据分析平台。