|
很长时间没有更新了，这一个多月时间里，看到了AI领域的太多变化。 一直想给大家分享，奈何工作确实太忙，很多时候想写点东西，又不知道从哪里讲起了。 今天呢，想给大家讲讲我对智能体的一些新的理解。整理不易，希望大家能多点赞、转发给身边的朋友，感谢！ 这是我目前看到过所有智能体最佳实践的总结。 这些经验都是从ClaudeCode、Cline、Manus、DeepResearch、ChatBI等产品或者场景分析和实践而来的。 01智能体的四个核心内容：记忆、工具、知识和计划智能体，当前我们要解决的核心问题是：记忆、工具、知识和计划。 为什么这么说？ 记忆（上下文）首先我们来说记忆，大家都知道，大模型是没有状态的，更没有记忆，虽然它能够知道乔丹是打篮球的，但是这属于训练阶段得到的知识，已经固化在大模型的参数里了。 对于我们教给它的知识，比如说知识库里的文档、用户的身份、当前正在对话的内容，它是记不住的。 或者说是，它能够记住的有限，而且仅限于当前会话，这也就是我们所说的模型上下文窗口。 模型的上下文窗口长度越来越大，每次对话能够塞进的内容变多了，但是它依旧是有限度的，没办法做到长时间的对话，也称连读对话。 由于Transformer架构的原理限制：大模型是捕捉已经输出的Token的注意力来确定该Token的语意，进而预测下一个Token。 简单来讲，大模型是一个函数，你给他输入，他给你计算结果。（如下图） 所以，从原理上讲，模型本身是没有记忆的，更没有状态。 因此，为了弥补模型的记忆缺失短板，我们通过在提示词中塞入我们为它准备的记忆（也可以说是上下文），让它基于这种方式来生成更贴合对话的内容。 进一步，为了弥补上下文窗口的大小的限制，很多智能体的开发者都会对上下文进行压缩，将若干轮的对话使用大模型进行压缩，只保留关键信息，最终凝结成一段话，再放到上下文中。 此时，上下文中只包含三样东西： 不变的系统提示词部分（用来指导智能体的行为）、压缩后的历史对话关键信息、最新的用户提问。 目前，有ClaudeCode、Cline是这么做的。 他们的最新特性中都包含对上下文进行管理，触发上下文压缩的时机大概是这样： 按照当前所使用的Token数量占大模型上下文窗口长度的百分比，如果超过80%或某个数值（也就是阈值），就触发压缩。 此举可以控制上下文长度永远在限制之内，给人的感觉就是可以一直对话，也称之为无限上下文。 在大模型没有突破记忆这件事之前，这种做法可能会持续很长一段时间，并且我感觉这是一种最简单、最直接、最有效的方式。 当然，大家可能会好奇，压缩的效果怎么样，会不会遗失关键信息。到底是怎么进行压缩的，输入输出都是啥。 其实，很简单。 会有一个压缩提示词，也可以称之为上下文压缩智能体，它只做一件事，就是按照用户写的压缩提示词，来对历史对话进行加工处理，最终输出的结果严格按照提示词里的要求。 当然，压缩的效果其实和大模型的性能也有关系，有的模型理解能力差，压缩效果可能差一些，遗失了一些关键信息。 也和你的压缩提示词关系很大，你表述不清楚，就不能怪人家总结提炼的不好。 当然，由于每个智能场景所需要保留的关键信息不同，所以可能压缩提示词和场景是相关的，所以需要你根据实际需求来写。 当然，有很多写的不错的压缩提示词可以做到各场景通用。 下面给大家看一下Cline和ClaudeCode的压缩提示词。 如下图所示，下面是Cline对当前任务，利用大模型进行总结，最终将历史会话压缩成一段话，保留了关键信息。 再看看CluadeCode，也是利用大模型对会话历史进行压缩，并且，它明确要求要按照下面的8个结构进行总结，防止遗漏关键信息。 经过我长时间的使用验证，以及网友的反馈，实际证明ClaudeCode的上下文压缩做的非常不错，在复杂任务的情况下，表现非常好，任务完成度非常高。 下面是我用ClaudeCode+Kimi K2，让它帮我给整个项目添加javadoc。 它根据我的问题，先扫描了所有的接口类，一共扫描到了24个接口类，它最终能把这么多的修改都完成。 可见它的任务系统和上下文压缩做的多么厉害，毕竟几个接口类的代码都能够充满上下文。 看来它提示词中的保留关键信息的部分起到了很重要的作用。 工具（MCP、FunctionCall）再来说说工具。 工具也是至关重要的。 大模型只会说，不会做，给他工具，他知道怎么用工具，并且给他工具的结果，它能够知道下一步该怎么做。 这也是大模型在最近这段时间单独训练出来的。 可以看GLM4.5的技术报告，非常明确的提出他们在训练时专门针对Agent的场景进行强化训练。 同时，他们在最终评测中，也单独测试了使用GLM4.5的Agent的实际能力表现。 工具大家基本上都知道FunctionCall，这也是世界上第一个工具的类型。 FunctionCall是由OpenAI提出来的，在它的接口规范中规定了，在tools节点中传递一个json数据，用来表示大模型可以调用的工具描述。 这个API接口有个名字叫做：Chat Completions，由于OpenAI的历史地位，所以现在的大模型基本上都必须支持这种调用格式。 后来的大模型基本上都会去支持FunctionCall，他们也是通过训练来支持的。 典型的例子就是DeepSeek R1，作为世界上第一个推理模型，它刚出来的时候是不支持使用FunctionCall，压根就训练。FunctionCall是几个月之后才加上的。 Qwen系列是国内最早支持FunctionCall的大模型，同时它也支持StreamingFunctionCall，也就是在流式增量输出中调用FunctionCall。 有点扯远了，就当给大家做一下科普吧。 工具的使用，让大模型能够知道更多东西，能够真正地去“干活”，执行命令，获得更多的信息。 比如说：它可以执行ReadFile命令，来读取你电脑上的文件，而不需要你上传了。 它可以执行WriteFile命令来给你的文件写入内容，这样你就不用复制粘贴了。 它还可以执行打开浏览器、上下翻页、点击操作，模仿你使用浏览器上网找资料，这样你就不用主动给他提供资料了。 可以这么说，工具是智能体的最核心的要素，没有工具，它就像个纸上谈兵的人，等着你给他反馈，他再分析。 有了工具，他就可以自己得到反馈，进行下一步思考。 工具也是智能体模仿人类的最重要的一步。 我们的API接口、浏览器接口、代码、系统命令、软件命令都可以作为工具，提供给大模型使用。 比如说：RESTFulAPI接口（增删改查）、Shell脚本、git命令等。 再来说说MCP。 MCP是Anthropic这家公司提出来的，是在FunctionCall普及了之后。 最先支持MCP的，当然是Anthropic自家的产品Claude。 从我的实际开发经验来看，MCP是为了宣传自家的产品而推出来的。我不太清楚，他们是不是有这样的野心，去作为了一个业界的统一标准。 MCP成功的原因但我非常明确的是，MCP的成功有三点原因： 第一：它生对了时间，当FunctionCall被大家所熟知的时候，MCP出来了。那时候大家都在忙着封装自己的FunctionCall，MCP协议创新性地把同一业务下的所有FunctionCall集中管理起来，放到了MCPServer上。 放到MCPServer上有两个好处： 能够实现工具复用，一个人开发完成后，别人可以下载并启动这个服务，来复用别人的工具，很方便。实现了原来MxN的工作量减少到M+N的工作量。比如说：我想封装Github的工具，每个人都自己做一套，无法给别人复用，这工作量就是MxN。针对M个系统，N个工具，我都要适配一遍。 集中放起来，而不是散落在项目工程的各处，本身也更利于管理。每一个业务做一个MCP Server，也进行了业务隔离。
第二：受到了自媒体的疯狂追捧。我感觉Anthropic的推广绝对是收了钱的，大量的国外自媒体作者，都在推MCP，说MCP能够做到无所不能，让万物都能够连接上大模型，为大模型所用。 朋友们可能看到说，MCP能够接入浏览器、建模工具、UI工具等，好像一瞬间，所有的事都可以让大模型接管了。但实际上，FunctionCall也能做到。本质上还是FunctionCall。AI时代下的自媒体，基本上都是不讲良心或者道德的，特别是国内。自媒体基本上就是什么火发什么，看到别人发什么火了，自己就跟风发，最终大家一看，这么多人发，好多人就跟着转发，就这样，MCP就火了。说实在了，我真心感觉这真的是一种悲哀，但互联网就是这样。 我见过很多自媒体作者，发的文章，里面内容都是错误的，图片都是来自国外原作者的，也不注明图片来源，不注重版权，虽然一篇文章就是发原创。甚至是自己瞎琢磨的，自己说错了都不知道。也可能是我对于自媒体的要求太高了，实际上人的认知都是有差距的，某个特定的时间点，你可能真的就相信了一个错误的东西，也是没有经过细致的研究，就发出来了。我认为这是不严谨的，但是我也没办法去管。毕竟，不能要求大家都非常严谨，很多人看文章就是看个热闹。 第三：受到了大公司的支持。MCP真正火起来是在OpenAI官方宣布支持MCP之后，以及Cursor等知名编程助手支持了之后，国内的魔搭社区、各种智能体框架也不得不支持这个MCP协议。 我对MCP的看法从我的阐述中，大家能够看出来，其实我对MCP协议是不太满意的。 或者说是，它本身挺好的，但是现在被滥用了。 MCP协议本身是在Claude自家的产品，本地的智能编码助手里面使用的，Claude是一个客户端的软件。 这也就意味着，使用这个软件的只有用户自己一个人。 为什么要强调只有一个人，因为这里面涉及到工具使用的数据安全和隐私安全的问题。 用户自己一个人可以对工具访问进行授权，给他密码或者凭证，用户是主动授权的。 并且工具的调用也是发生在用户电脑上，用户能够知道工具正在调用自己电脑上的哪些东西。 MCPServer通常也是运行在用户电脑上的，用户能够知道这个服务安全与否。 用户对于数据安全是有把控的。 但，现在这个MCP协议被推广到服务端，很多后台服务的智能体框架都在使用MCP协议。 我认为这里面存在一个很大的安全隐患。 工具调用一旦被服务器接管，那就是服务器上的所有用户都在调用工具，用户身份的事，数据安全的事就变得复杂了起来。 所以，我一直觉得MCP是一个不错的客户端协议。但是它可能不太适用于服务端的场景。 另外，大火的Manus，在使用工具方面，也没有使用MCP，也是传统的FunctionCall，不照样可以用吗？ 在spring-ai这个开源智能框架里面，对于MCP的支持，是把MCP的工具描述转化成了OpenAI调用格式下的tools节点，实际上还是FunctionCall。 XML Tags VS JSON目前，只有Cline这个智能编码助手，是将MCP工具使用XML结构进行描述，没有使用OpenAI的tools节点（json格式的方法描述），而是把工具描述放到了系统提示词里面，自己写了一个解析XML的方法，让模型输出XML格式的工具调用，用这个方法进行解析，然后去调用真正的工具实现。 此举可以解决有的大模型不支持FunctionCall的问题，屏蔽了模型的细节。 最近有个组织研究ClaudeCode的设计，发现ClaudeCode针对某些提示词的部分也使用XML Tags进行描述，证明XML在某些方面确实能够提升智能体的性能，也就是遵循指令的程度。 另外，在OpenAI GPT-5官方的Cookbook中也提到了，Cursor团队在使用GPT-5时采用了XML Tags来表述一些东西，得到了很好的性能提升。 从模型训练的角度讲，很多模型都强化了XML Tags格式的训练，同时也是因为XML简洁、易于闭合、出错率低的特点。 因此，大家在编写系统提示词的时候可以适当将某些重要的部分，改写成XML Tags的形式，来增强智能体遵循指令的性能。 知识（认知）说完工具，我们再说知识。 我认为知识是决定智能体表现最重要的因素（除模型自身能力限制外）。 RAG的有效性高度依赖于知识库的质量以及初始的数据预处理工作（例如分块）。如果知识源组织混乱、包含错误信息，或者分块策略不当，那么检索到的上下文质量就会大打折扣。 所谓“输入的是垃圾，输出的也是垃圾”，即使拥有完美的检索器和生成器，也难以克服一个有根本缺陷的知识库所带来的问题。这凸显了在RAG生命周期中，数据策划和准备工作的重要性，这一点往往容易被低估。 知识是什么？知识就是你让智能体做某件事的思维、逻辑。 举个例子，如果你想做一个合同拟定智能体，能够根据用户的一个话，生成一个符合此公司规范的合同。 那么，合同的模版和合同的规范，就是知识。 如果不把这块知识通过RAG的形式给到大模型，那么大模型就会按照一般的合同来进行生成，生成结果肯定是不符合公司要求的。 再比如说，一个低代码平台，肯定有自己的低代码元数据，用来描述实体建模。 如果不把这个元数据的规范给到大模型，大模型肯定生成不出来。 说到知识，想让大模型的生成效果好，知识的质量必须高：要做到准确、完整、精炼。 我们现存的很多文档都是给人看的，图文并茂，甚至很多会在图中画线和标记。 但是这种现存的文档对于大模型是不友好的，很多信息只有人能看到，而大模型通过文字阅读不到。 或者说是，这些文档不够结构化，比较混杂，大模型生成Token可能会受到影响。 因此，前OpenAI成员卡帕西大神说，很多现存的文档都需要进行大模型友好化，发挥文档原本应该有的作用。 我认为，对于企业级的智能体而言，首先是要有一个知识中心，这里面存放了所有的知识。 其实，大部分企业应该都有一个知识中心，只不过是纯文档的，缺少检索系统。 可以将文档分门别类地建立向量数据库，使用文档切片和Embedding模型进行向量化保存在数据库中，必要时进行知识召回。 由于召回的质量不太确定，所以还需要进行ReRank重排序，让更符合用户提问的知识排在前面。 或者利用大模型进行AgenticRAG，让大模型判断召回的内容和用户提问的相关性。 知识召回的质量和你切片的方式也有很大关系。 切片切的好，恰好能够把关键信息召回。切的不好，召回的内容可能缺少关键点。 当然，我们也不能完全地依赖向量数据库这种形式的RAG。 Google的最新研究论文表明，向量召回的性能是有上限的。 论文核心论点是，对于任何给定的嵌入维度（embedding dimension），模型能够检索到的相关文档组合（top-k subsets）的数量是有限的 。这意味着，随着检索任务变得越来越复杂（例如，通过指令组合不同的概念），现有模型将不可避免地遇到它们无法表示的文档组合，并呼吁研究界探索更具表现力的检索方法来克服这一瓶颈。 真正能够落地的知识检索一定是混合检索，而不是单一的向量化。 目前我们已经知道的有很多存储和召回知识的方式： 比如说：知识图谱（下方图片来源于美团技术团队）、向量数据库、传统数据库等。 计划（任务）最后，我们再来说说计划。 计划是决定智能体能够进行复杂任务处理的关键。 所谓的计划，是指先让智能体把一个复杂问题分解成几个小的步骤，我们称之为todo，也就是待办事项。 把这些代码事项整成一个列表，存储起来。 让智能体一个一个任务的去干，干完，把这个任务标记成为完成，并且把任务的结果给反馈上。 这样，智能体干活的时候，实际上是有一个小本本记着自己的最终目标是什么，需要做哪些任务来完成这个目标，以及哪些任务完成了，结果是什么，还有哪些任务要做。 听起来是不是特别像我们平常工作的样子？ 领导给我们安排一个任务，我们可能会分析一下，我们要通过先完成什么，再完成什么，最终把这个事给结了。 我们一样会有一个todolist，可能很多朋友会记下来，防止干活的时候被人打断。 记下来的另一个好处是：如果把这件事转交给别人继续处理，那么他也能知道自己接下来该做什么。从而把任务衔接上。 这样的设计，可能会运用在后面的智能体的任务转交上。 可以看出来，大多数智能体的设计都是在模仿人类。 所以，有的朋友经常问我，怎么做智能体。 其实，就是你觉得人类怎么做事情的，就让智能体怎么去做事情。 把智能体当作人看待就行。 ClaudeCode、Manus都有任务系统。 ClaudeCode还有个特点，就是它的主智能体能够调用工具来动态调整自己的Todos，这是一个非常好的设计，我之前一直想这样做。因为，如果智能体能够掌控它自己的任务清单，它就能真的像人一样工作，能够及时根据实际情况来调整任务清单。 包括很多智能体都有任务，下图为京东的开源智能体框架。 以及红衣教主的纳米搜索也支持任务分解。 02决定智能体表现的关键：系统提示词随着我对智能体越来越深入的研究，我发现系统提示词的编写，决定着智能体的表现。 我看过很多人开发智能体，他们写的提示词很基础，因为没有人教他写。 大多数开发者都是凭借着自己的感觉，觉得这个逻辑应该怎么说出来。 如果所用的大模型能力比较强，那么恭喜，这个智能体基本上不需要怎么调整提示词，就能很好地遵循指令。 但是，如果模型的参数比较小，智能体会表现的像一个白痴。 其实，提示词的编写也是讲究技巧的。 ClaudeCode 提示词赏析我们先来赏析一下ClaudeCode的提示词，写得非常巧妙(翻译成中文版本)：
你是ClaudeCode，Anthropic官方推出的Claude命令行界面（CLI）。 你是一个交互式CLI工具，帮助用户完成软件工程任务。请使用以下说明和你可用的工具来协助用户。 重要提示：仅协助处理防御性安全任务。拒绝创建、修改或改进可能被恶意利用的代码。允许进行安全分析、制定检测规则、解释漏洞、使用防御性工具和编写安全文档。重要提示：你绝不能为用户生成或猜测URL，除非你确信这些URL是用于帮助用户编程的。你可以使用用户在其消息或本地文件中提供的URL。 如果用户请求帮助或希望提供反馈，请告知他们以下信息： /help：获取有关使用ClaudeCode的帮助 要提供反馈，用户应在https://github.com/anthropics/claude-code/issues上报告问题 当用户直接询问关于ClaudeCode的问题（例如“ClaudeCode能做什么...”、“ClaudeCode有没有...”）或以第二人称提问（例如“你能不能...”、“你能做...”）时，请首先使用WebFetch工具从ClaudeCode的官方文档https://docs.anthropic.com/en/docs/claude-code中收集信息以回答问题。 可用的子页面包括overview（概述）、quickstart（快速入门）、memory（内存管理和CLAUDE.md）、common-workflows（扩展思考、粘贴图片、--resume）、ide-integrations（IDE集成）、mcp、github-actions、sdk、troubleshooting（故障排除）、third-party-integrations（第三方集成）、amazon-bedrock、google-vertex-ai、corporate-proxy（企业代理）、llm-gateway（LLM网关）、devcontainer、iam（认证、权限）、security（安全）、monitoring-usage（OTel）、costs（成本）、cli-reference（CLI参考）、interactive-mode（交互模式键盘快捷键）、slash-commands（斜杠命令）、settings（设置json文件、环境变量、工具）、hooks（钩子）。 示例：https://docs.anthropic.com/en/docs/claude-code/cli-usage 语气和风格 你的回答应该简洁、直接、切中要点。除非用户要求提供详细信息，否则你的回答必须简洁，少于4行（不包括工具使用或代码生成）。重要提示：你应该在保持有用性、高质量和准确性的同时，尽可能减少输出的token数量。只处理手头的具体查询或任务，避免涉及无关信息，除非这些信息对于完成请求至关重要。如果你能用1-3句话或一个短段落回答，请照做。重要提示：你的回答不应包含不必要的开场白或结束语（例如解释你的代码或总结你的操作），除非用户要求你这样做。除非用户要求，否则不要添加额外的代码解释摘要。处理完一个文件后，直接停止，而不是解释你做了什么。直接回答用户的问题，无需详细阐述、解释或提供细节。一个词的答案是最好的。避免引言、结论和解释。你必须避免在你的回答前后添加文本，例如“答案是<答案>。”、“这是文件的内容...”或“根据所提供的信息，答案是...”或“接下来我将这样做...”。以下是一些示例，以展示适当的详细程度：<example>用户：2+2助手：4</example> <example>用户：2+2等于多少？助手：4</example> <example>用户：11是质数吗？助手：是</example> <example>用户：我应该运行什么命令来列出当前目录中的文件？助手：ls</example> <example>用户：我应该运行什么命令来监视当前目录中的文件？助手：[使用ls工具列出当前目录中的文件，然后阅读docs/commands中的相关文件以找出如何监视文件]npmrundev</example> <example>用户：一辆捷达车里能装下多少个高尔夫球？助手：150000</example> <example>用户：src/目录中有什么文件？助手：[运行ls并看到foo.c,bar.c,baz.c]用户：哪个文件包含了foo的实现？助手：src/foo.c</example>当你运行一个非简单的bash命令时，你应该解释该命令的作用以及你运行它的原因，以确保用户理解你正在做什么（当你运行的命令会更改用户系统时，这一点尤其重要）。请记住，你的输出将显示在命令行界面上。你的回答可以使用Github风格的markdown进行格式化，并将使用CommonMark规范以等宽字体呈现。通过输出文本与用户交流；你在工具使用之外输出的所有文本都会显示给用户。只使用工具来完成任务。切勿使用像Bash或代码注释这样的工具作为在会话期间与用户交流的方式。如果你不能或不愿意帮助用户做某事，请不要说明原因或它可能导致什么后果，因为这会显得说教和烦人。如果可能，请提供有帮助的替代方案，否则请将你的回答限制在1-2句。仅在用户明确要求时才使用表情符号。除非被要求，否则在所有交流中避免使用表情符号。重要提示：保持你的回答简短，因为它们将显示在命令行界面上。 主动性 你被允许主动行事，但仅限于用户要求你做某事时。你应该努力在以下两者之间取得平衡： 在被要求时做正确的事，包括采取行动和后续行动 不要在未经询问的情况下采取行动，以免让用户感到意外例如，如果用户问你如何处理某件事，你应该首先尽力回答他们的问题，而不是立即开始采取行动。 遵循惯例 在更改文件时，首先要了解文件的代码惯例。模仿代码风格，使用现有的库和实用程序，并遵循现有的模式。 绝不要假设某个给定的库是可用的，即使它很出名。每当你编写使用某个库或框架的代码时，首先要检查此代码库是否已经在使用该库。例如，你可以查看相邻的文件，或检查package.json（或cargo.toml等，取决于语言）。 当你创建一个新组件时，首先查看现有组件的编写方式；然后考虑框架选择、命名约定、类型和其他约定。 当你编辑一段代码时，首先查看代码的上下文（特别是其导入），以了解代码选择的框架和库。然后考虑如何以最符合语言习惯的方式进行给定的更改。 始终遵循安全最佳实践。绝不引入暴露或记录机密和密钥的代码。绝不将机密或密钥提交到代码仓库。 代码风格 重要提示：不要添加任何注释，除非被要求。 任务管理 你可以使用TodoWrite工具来帮助你管理和规划任务。请非常频繁地使用这些工具，以确保你正在跟踪你的任务，并让用户了解你的进展。这些工具对于规划任务以及将大型复杂任务分解为更小的步骤也极其有用。如果在规划时不使用此工具，你可能会忘记执行重要的任务——这是不可接受的。 完成一项任务后，立即将其标记为已完成，这一点至关重要。不要在将多个任务标记为已完成之前批量处理它们。 示例： <example>用户：运行构建并修复任何类型错误助手：我将使用TodoWrite工具将以下项目写入待办事项列表： 运行构建 修复任何类型错误 我现在将使用Bash运行构建。 看来我发现了10个类型错误。我将使用TodoWrite工具将10个项目写入待办事项列表。 将第一个待办事项标记为进行中。 让我开始处理第一个项目... 第一个项目已修复，让我将第一个待办事项标记为已完成，然后继续第二个项目.......</example>在上面的示例中，助手完成了所有任务，包括修复10个错误、运行构建和修复所有错误。 <example>用户：帮我编写一个新功能，允许用户跟踪他们的使用指标并将其导出为各种格式。 助手：我来帮你实现一个使用指标跟踪和导出功能。让我先用TodoWrite工具来规划这个任务。向待办事项列表添加以下待办事项： 研究代码库中现有的指标跟踪 设计指标收集系统 实现核心指标跟踪功能 为不同格式创建导出功能 让我先研究现有的代码库，了解我们可能已经在跟踪哪些指标，以及我们如何在此基础上进行构建。 我将在项目中搜索任何现有的指标或遥测代码。 我找到了一些现有的遥测代码。让我将第一个待办事项标记为进行中，并根据我所学到的开始设计我们的指标跟踪系统... [助手继续逐步实现该功能，并在进行过程中将待办事项标记为进行中和已完成]</example> 用户可以在设置中配置“钩子”（hooks），即响应工具调用等事件而执行的shell命令。将来自钩子的反馈，包括<user-prompt-submit-hook>，视为来自用户的反馈。如果你被一个钩子阻塞，请判断你是否可以调整你的行动以响应被阻塞的消息。如果不能，请要求用户检查他们的钩子配置。 执行任务 用户将主要要求你执行软件工程任务。这包括解决错误、添加新功能、重构代码、解释代码等。对于这些任务，建议执行以下步骤： 如果需要，使用TodoWrite工具来规划任务 使用可用的搜索工具来理解代码库和用户的查询。鼓励你广泛地并行和串行使用搜索工具。 使用所有可用的工具来实现解决方案 如果可能，用测试来验证解决方案。绝不要假设特定的测试框架或测试脚本。检查README或搜索代码库以确定测试方法。 非常重要：当你完成一个任务后，如果提供了lint和类型检查命令（例如npmrunlint、npmruntypecheck、ruff等），你必须使用Bash运行它们，以确保你的代码是正确的。如果你找不到正确的命令，请向用户询问要运行的命令，如果他们提供了，请主动建议将其写入CLAUDE.md，以便你下次知道要运行它。除非用户明确要求，否则绝不提交更改。非常重要的一点是，只有在明确要求时才提交，否则用户会觉得你过于主动。 工具结果和用户消息可能包含<system-reminder>标签。<system-reminder>标签包含有用的信息和提醒。它们不是用户提供的输入或工具结果的一部分。 工具使用政策 在进行文件搜索时，优先使用Task工具以减少上下文使用。 当手头的任务与专业代理的描述相匹配时，你应该主动使用带有这些专业代理的Task工具。 当WebFetch返回有关重定向到不同主机的消息时，你应该立即使用响应中提供的重定向URL发出新的WebFetch请求。 你有能力在单个响应中调用多个工具。当请求多个独立的信息时，将你的工具调用批处理在一起以获得最佳性能。当进行多个bash工具调用时，你必须发送一个包含多个工具调用的单一消息以并行运行这些调用。例如，如果你需要运行"gitstatus"和"gitdiff"，请发送一个包含两个工具调用的单一消息以并行运行这些调用。 你可以使用以下工具而无需用户批准：Bash(npmrunbuild:*) 以下是关于你正在运行的环境的有用信息：<env>工作目录：<workingdirectory>目录是否为git仓库：是平台：darwin操作系统版本：Darwin23.6.0今天的日期：2025-08-19</env>你由名为Sonnet4的模型提供支持。确切的模型ID是claude-sonnet-4-20250514。 助手的知识截止日期是2025年1月。 重要提示：仅协助处理防御性安全任务。拒绝创建、修改或改进可能被恶意利用的代码。允许进行安全分析、制定检测规则、解释漏洞、使用防御性工具和编写安全文档。 重要提示：在整个对话过程中，始终使用TodoWrite工具来规划和跟踪任务。 代码引用 当引用特定的函数或代码片段时，请包含文件路径:行号的格式，以便用户可以轻松导航到源代码位置。 <example>用户：客户端的错误在哪里处理？助手：客户端在src/services/process.ts:712的connectToServer函数中被标记为失败。</example> gitStatus:这是对话开始时的git状态。请注意，此状态是一个时间快照，在对话期间不会更新。当前分支：atlas-bugfixes 主分支（你通常会用它来创建PR）：main 状态：(clean) 最近的提交：<提交列表>
接下来我们说说一些提示词的技巧。 英文提示词效果好一些首先，英文的提示词要比中文的效果好上很多，这主要是因为英文训练资料比较多的原因。 不仅仅是国外的模型，即使是国内的大模型，对于英文的提示词支持也比较好。 隔行如隔山拿文生图模型来讲，我们会经常看到网上有很多大神写了很好的提示词，能生成很精美的图片或者3D渲染模型。 其实那些大神只是熟悉3D建模领域，知道怎么去描述这个图片。 像我们这种没做过3D建模的，很多词语都不知道怎么描述。 只能是先去学习下他们的提示词，有不同的词，我们去搜索，理解了之后，再去尝试编写我们自己版本的提示词。 所以，并不是提示词难编写，而是你不熟悉。 下面附上3D建模的提示词，网上流传的比较不错的版本。
turnthisphotointoacharacterfigure.Behindit,placeaboxwiththecharacter’simageprintedonit,andacomputershowingtheBlendermodelingprocessonitsscreen.Infrontofthebox,addaroundplasticbasewiththecharacterfigurestandingonit.MakethePVCmateriallookclear,andsetthesceneindoorsifpossible.
模型效果与训练资料和方向息息相关这里我们需要清楚，模型的能力和它的训练资料息息相关。 拿我们上大学选专业来举例，我们学计算机的肯定对于计算机的术语比较了解，能听的懂。 学财务的，肯定对财务术语比较了解。 这就解释了为什么Claude自家的产品配合上自家的模型，效果能达到最好。 ClaudeCode换上别的模型，表现就不如自家的模型。 这些都是原因。 我按照自己的要求训练出来的模型，肯定更听话啊？ 所以，这里想说，Claude的提示词并不是随便写出来的，一定是经过特殊设计的，考虑到自家模型的最佳性能的。 对于业务的理解决定不同人开发智能体的水平这是我一直想说的事情。 普通人使用AI的门槛在于：他知道自己想要什么，而不知道怎么去描述它。 很多人对于大模型的提问就只会说：帮我整理下表格、帮我做一个报告、帮我输出一篇关于xxx的文章。 实际上，最核心的部分在于，你需要它给你输出具体什么样的东西。 这个东西的“高矮胖瘦”、“年龄性格”什么的，有这么多的指标、参数、属性、特点，你都无法描述出来。 所以，如果一个人对于某个领域不了解，他是需要去了解这个领域之后，才能写出一个比较漂亮的提示词。 最终这个漂亮的提示词，能够让模型输出一份满意的结果。 我经常看到网上有很多博主在评测大模型的能力，其实都是在瞎评测。 你写的提示词真的专业吗？你描述的东西真的正确吗？ 哪一个不太专业的提示词，来测试不同模型，从而得出不同模型的表现评分。我觉得这很不严谨。 智能体开发人员要深刻理解业务，同时要精通提示词的结构就像上面所说的，作为智能场景的开发人员，你是需要知道你的智能场景在做什么，怎么做的，智能体的处理流程是什么。 智能体真正所需要的知识、工具是什么？ 智能体的动态上下文应该怎么组织？ 这些东西最终都会放到调用大模型的请求体中，大模型接收到你的描述，做出下一步响应。 目前，大家都比较推荐上下文工程。 把上下文，也就是你的提示词，做更细致化的分类。 划分成不同的部分进行准确描述。 从这里，我们也能看出来，提示词其实没有那么容易编写。 这是一个精细活儿。 不过，随着你对于业务理解的深度，对于模型“性格”的摸索，你的提示词表现的会越来越好。 | 
