跳至主要内容

实作指南

AI 智能体进化论:顶尖开发者如何为 Claude 打造高效工具?

你的 AI 智能体(Agent)是否感觉有点笨拙,无法发挥全部潜力?问题可能不在 AI 本身,而在于你给它的“工具”。本文将揭示 Anthropic 的内部心法,分享如何打造、评估并优化 AI 工具,甚至让 Claude 协助你完成这一切,让你的 AI 应用程序效能倍增。

你的 AI 智能体(Agent)是否感觉有点笨拙,无法发挥全部潜力?问题可能不在 AI 本身,而在于你给它的“工具”。本文将揭示 Anthropic 的内部心法,分享如何打造、评估并优化 AI 工具,甚至让 Claude 协助你完成这一切,让你的 AI 应用程序效能倍增。


你有没有过这种感觉?你手上有一个像 Claude 这样强大的大型语言模型(LLM),理论上它应该能自动处理复杂任务,但实际运作起来却总是有点卡卡的,不够聪明。这就像你请了一位米其林星级主厨,却只给他一把钝刀和几个不新鲜的食材。

问题的根源,往往不是主厨的能力,而是我们提供给他的工具。

AI 智能体(Agent)的效能,与我们赋予它的工具有着最直接的关系。这篇文章,就是要分享我们在 Anthropic 内部,透过无数次实验总结出的经验:如何打造高质量的工具,如何进行全面的评估,以及最有趣的部分——如何与 Claude 这类的 AI 协作,让它自己来优化自己的工具。

所以,AI 的“工具”到底是什么?

在我们深入探讨之前,得先厘清一个观念。传统的软件开发,就像是写一份精确的食谱。只要输入相同的食材(inputs),每一步都完全照做,最终产出的菜肴(output)永远都会一模一样。这就是所谓的“确定性系统”(deterministic systems)。

但 AI 智能体不一样。它更像一位有创造力的厨师,即使拿到相同的食材,也可能根据当下的灵感,做出稍微不同的变化。它是一个“非确定性系统”(non-deterministic systems),充满了变数与可能性。

因此,为 AI 设计的“工具”,是一种全新的软件。它不再是死板的指令集,而更像是在确定性系统与非确定性智能体之间建立的一份“合约”。当使用者问“今天出门要带伞吗?”,智能体可能会呼叫天气工具,也可能从自身知识回答,甚至会反问地点。它可能会出错,也可能找不到合适的工具。

这意味着我们必须彻底改变思维。我们设计的不再是给其他开发者用的 API,而是给一个充满不确定性、需要引导的“数字大脑”使用的工具。

如何打造高效工具?一个不断循环的开发流程

想打造出让 AI 用得顺手的工具,并不是一蹴可几的事。这是一个不断“打造、评估、学习”的循环过程。

步骤一:别想太多,先动手做个原型

要预测 AI 会觉得哪些工具“顺手”,哪些会让它“困惑”,光靠想像是没用的。最好的方法就是直接动手。

你可以利用像 Claude Code 这样的工具,快速生成你的工具原型。一个小技巧是,提供它相关的软件库、API 或 SDK 文件,特别是那些 LLM 友善的纯文本文件(很多开源专案会提供 llms.txt 这种档案),这会让它事半功倍。

原型写好后,将它包装成本地的 模型上下文协议(MCP)服务器 或 桌面扩充功能(DXT),就可以在 Claude Code 或 Claude 桌面应用程序中进行测试。你也可以直接透过 Anthropic API 进行程序化测试。

亲自测试你的工具,感受一下流程是否顺畅,并收集使用者的回馈,这能帮助你建立对使用情境的直觉。

步骤二:是时候来场严格的“大考”了

原型有了,接下来你需要衡量 Claude 使用这些工具的表现如何。这需要一套全面的评估机制。

忘掉那些过于简单的“沙盒”环境吧!你需要的是源于真实世界、具有足够复杂度的评估任务。一个好的评估任务,可能需要 AI 连续呼叫多个、甚至数十个工具才能完成。

看看这两组任务的差别:

  • 好的评估任务范例:

    • “帮我跟 Jane 约下周开会,讨论最新的 Acme 公司专案。从上次的专案规划会议纪录中附加笔记,并预订一间会议室。”
    • “客户 ID 9182 回报他一次购买被重复收费了三次。找出所有相关的日志记录,并判断是否有其他客户也受到影响。”
  • 较弱的评估任务范例:

    • “跟 jane @ acme.corp 约下周开会。”
    • “搜寻 customer_id=9182 的付款日志。”

看到差别了吗?好的任务更贴近真实的工作流程。

每个评估任务都应该有一个可验证的结果。最简单的方式是比对字符串,复杂一点则可以让另一个 Claude 实例来判断结果是否正确。同时,你也可以在系统提示(System Prompt)中,要求 AI 在呼叫工具前回传它的“推理过程”和“反馈”,这能触发它的“思维链(Chain-of-Thought)”行为,提升解决问题的智慧。

步骤三:让 AI 成为你的最佳分析师

评估跑完,一堆数据摊在眼前,然后呢?

这时候,AI 智能体本身就是你最好的合作伙伴。它们能帮你发现从工具描述互相矛盾,到工具实作效率低下等各种问题。但请记住一个重点:大型语言模型并不总是直话直说,它“没说什么”往往比它“说了什么”更重要。

仔细观察你的 AI 在哪些地方卡住或感到困惑。阅读它的推理过程(CoT),找出那些不顺畅的地方。你甚至可以把整个评估过程的脚本(包含工具呼叫和回传)直接贴给 Claude Code,它是一位分析脚本和重构工具的专家,能确保你在修改后,工具的实作和描述依然保持一致。

事实上,这篇文章里的大部分建议,都来自于我们内部不断用 Claude Code 优化工具的实践。透过这种方式,我们发现效能提升甚至超越了由专家研究员手动撰写的工具。

打造高效工具的五大黄金准则

在经历了无数次的迭代循环后,我们提炼出了几个关键的设计准则。

准则一:少即是多,别让你的 AI 选择困难

一个常见的误区是,以为给 AI 的工具越多越好。但事实恰恰相反。如果只是简单地将现有的 API 功能一对一地封装成工具,往往会造成反效果。

AI 智能体的“上下文(context)”是有限的,就像人的短期记忆一样。而传统计算机的内存则几乎是无限的。想象一下,在通讯录里找一个人,传统软件可以快速遍历整个列表。但如果一个工具回传了“所有”联络人,让 AI 一个个去读,那无疑是在浪费它宝贵的上下文空间。

更聪明、更自然的方式,是像人一样,直接跳到相关的页面(例如按字母排序查找)。

所以,你应该设计的是针对特定高影响力工作流程的工具。例如,与其提供 list_users、list_events、create_event 三个工具,不如整合一个 schedule_event 工具,一步到位地完成查找空闲时间并安排活动。

准则二:整理你的工具箱,命名是一门艺术

当你的 AI 可以取用数十甚至数百种工具时,混乱就会产生。如果工具功能重叠或用途模糊,AI 很容易就会用错。

命名空间(Namespacing) 是个简单却有效的解决方案。透过给相关工具加上共同的前缀来分组,可以帮助 AI 在正确的时间选择正确的工具。例如:

  • 按服务分类:asana_search, jira_search
  • 按资源分类:asana_projects_search, asana_users_search

这样做不仅减少了 AI 上下文需要加载的工具数量,也将一部分运算负担从 AI 的“大脑”转移到了工具本身,从而降低了出错的风险。

准则三:只说重点,AI 的“注意力”很宝贵

工具的回传内容也同样重要。请务必只回传高价值的、与上下文高度相关的资讯。

AI 更擅长处理自然语言的名称或术语,而不是像 uuid 这种神秘的技术标识符。我们发现,仅仅是将一长串无意义的字母数字 ID 解析成语义更丰富的语言,就能显著提高 Claude 在检索任务中的准确性并减少幻觉。

在某些情况下,你也可以提供弹性。例如,新增一个 response_format 参数,让 AI 可以选择回传“精简(concise)”或“详细(detailed)”的结果。精简版可能只包含核心内容,而详细版则包含各种 ID,方便后续的工具呼叫。

准则四:精打细算,教你的 AI 节省“脑容量”

上下文质量很重要,但“数量”同样需要优化。工具的上下文长度是有限的,因此你需要实作像是分页(pagination)、范围选择(range selection) 和 过滤(filtering) 等功能。

如果你的工具回传结果被截断了,一定要给予清晰的提示,引导 AI 采取更节省 Token 的策略,例如进行多次小范围的精准搜寻,而不是一次大范围的模糊搜寻。

同样地,错误讯息也至关重要。与其回传一个冰冷的错误码,不如提供一个有帮助的回应,清楚地说明问题所在,并给出修正建议。

看看这个对比:

  • 无用的错误: {"error": {"code": "RESOURCE_NOT_FOUND"}}
  • 有用的错误: “# 资源未找到:无效的 userId。您的请求失败,因为 userId ‘john.doe @ acme.corp’ 不存在或格式错误。有效的 userId 范例为:‘192829814…’。您可以尝试呼叫 user_search() 来解决此问题。”

后者显然能更好地引导 AI 走上正确的道路。

准则五:最强大的杠杆——一句好的描述胜过千行程式码

终于,我们来到了最有效、也最常被忽略的一环:为你的工具撰写描述(prompt-engineering your tool descriptions)。

工具的描述和规格会被加载到 AI 的上下文中,直接影响它的行为。撰写时,想象一下你正在向一位新加入团队的同事解释这个工具。把那些你可能认为理所当然的背景知识——特定的查询格式、专业术语的定义、资源之间的关系——全部明确地写出来。

避免模糊不清,特别是参数命名。不要用一个模糊的 user,而是用一个明确的 user_id。

微小的改动就能带来巨大的效能提升。例如,Claude Sonnet 3.5 在 SWE-bench 验证评估中取得顶尖表现,正是因为我们对工具描述进行了精确的微调,从而大幅降低了错误率。

展望未来:与 AI 共同进化的开发新模式

为 AI 智能体打造工具,要求我们将软件开发的思维模式,从可预测的确定性世界,转向充满变化的非确定性世界。

透过我们所描述的这种迭代式、以评估为驱动的开发流程,你会发现高效的工具都具备一些共通特点:它们目标明确、善用 AI 的上下文、可以灵活组合,并能让 AI 直观地解决真实世界的问题。

未来,随着 LLM 本身和 MCP 这类互动协议的不断升级,AI 与世界互动的方式也将不断进化。但只要我们坚持这种系统性的优化方法,就能确保我们手中的工具,能与日益强大的 AI 并肩前行,共同成长。

文章来源

https://www.anthropic.com/engineering/writing-tools-for-agents

谢谢你,读到这里。

保持好奇,明天继续探索。

© 2026 Communeify. All rights reserved.