今天，我想分享我对智能体的新理解。这些经验基于对ClaudeCode、Cline、Manus、DeepResearch和ChatBI等产品的分析与实践，总结了智能体领域的最佳实践。
让我们直入主题：智能体开发体系如何构成？如何让智能体更高效地工作？

01 智能体的四个核心内容：记忆、工具、知识和计划

智能体，当前我们要解决的核心问题是：记忆、工具、知识和计划。

记忆（上下文）

首先我们来说记忆，大家都知道，大模型是没有状态的，更没有记忆，虽然它能够知道乔丹是打篮球的，但是这属于训练阶段得到的知识，已经固化在大模型的参数里了。

对于我们教给它的知识，比如说知识库里的文档、用户的身份、当前正在对话的内容，它是记不住的。或者说是，它能够记住的有限，而且仅限于当前会话，这也就是我们所说的模型上下文窗口。

模型的上下文窗口长度越来越大，每次对话能够塞进的内容变多了，但是它依旧是有限度的，没办法做到长时间的对话，也称连读对话。

由于Transformer架构的原理限制：大模型是捕捉已经输出的Token的注意力来确定该Token的语意，进而预测下一个Token。

简单来讲，大模型是一个函数，你给他输入，他给你计算结果（如下图），所以，从原理上讲，模型本身是没有记忆的，更没有状态。

因此，为了弥补模型的记忆缺失短板，我们通过在提示词中塞入我们为它准备的记忆（也可以说是上下文），让它基于这种方式来生成更贴合对话的内容。

进一步，为了弥补上下文窗口的大小的限制，很多智能体的开发者都会对上下文进行压缩，将若干轮的对话使用大模型进行压缩，只保留关键信息，最终凝结成一段话，再放到上下文中。

此时，上下文中只包含三样东西：

• 不变的系统提示词部分（用来指导智能体的行为）
• 压缩后的历史对话关键信息
• 最新的用户提问

目前，ClaudeCode、Cline是这么做的。他们的最新特性中都包含对上下文进行管理，触发上下文压缩的时机大概是这样：按照当前所使用的Token数量占大模型上下文窗口长度的百分比，如果超过80%或某个数值（也就是阈值），就触发压缩。


这种方式能将上下文长度始终控制在限制范围内，给人"无限对话"的体验，因此被称为"无限上下文"。

在记忆机制取得突破之前，这很可能是长期主流的解决方案——它简单、直接且极其有效。

当然，你可能会担心压缩效果、信息丢失以及具体的输入输出机制。

其实答案很简单：选用合适的压缩提示词。

上下文压缩智能体（压缩提示词）是一种专门的提示词系统，它严格按照用户定义的压缩规则处理历史对话，确保输出完全符合预设要求。

压缩效果取决于两个关键因素：大模型的理解能力和提示词设计的清晰度。模型性能不足可能导致关键信息丢失；而模糊的提示词指令同样会影响压缩质量。

由于不同智能场景需要保留的信息各异，压缩提示词往往需要针对性设计。当然，也存在许多经过验证的通用型提示词，能够适应多种场景需求。

下面给大家看一下Cline和ClaudeCode的压缩提示词：

如下图所示，下面是Cline对当前任务，利用大模型进行总结，最终将历史会话压缩成一段话，保留了关键信息。

再看看CluadeCode，也是利用大模型对会话历史进行压缩，并且它明确要求要按照下面的8个结构进行总结，防止遗漏关键信息。

经过我长时间的使用验证和网友反馈，ClaudeCode的上下文压缩能力确实非常出色，在复杂任务下表现优异，任务完成度极高。

比如我用ClaudeCode+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出来了。MCP协议创新性地把同一业务下的所有 FunctionCall 集中到 MCPServer 管理。

这带来两大好处：

1. 实现工具复用，一个人开发完成后，别人可以下载并启动这个服务，来复用别人的工具，很方便。实现了原来MxN的工作量减少到M+N的工作量。比如说：我想封装Github的工具，每个人都自己做一套，无法给别人复用，这工作量就是MxN。针对M个系统，N个工具，我都要适配一遍。
2. 集中管理，而不是散落在项目工程的各处。每一个业务做一个MCP Server，便于维护且实现业务隔离。
   
   第二：自媒体的热捧。国外自媒体大力推广MCP，称其无所不能，能让万物接入大模型。

MCP能够接入浏览器、建模工具、UI工具等，好像一瞬间，所有的事都可以让大模型接管了。但实际上，FunctionCall也能实现，且其本质上还是FunctionCall。

第三：大公司鼎力支持。OpenAI官方宣布支持MCP，加上Cursor等知名编程助手的集成，让MCP迅速火爆，国内魔搭社区和各类智能体框架也相继跟进支持MCP协议。

我对MCP的看法

从我的阐述中可以看出，其实我对MCP协议是不太满意的。或者说，它本身挺好的，但是现在被滥用了。

MCP协议原本是Claude用于自家本地智能编码助手的，这意味着使用场景是单用户的——只有用户自己使用。

强调"只有一个人"很重要，因为这涉及数据安全和隐私问题。

在单用户场景下，用户可以自主授权工具访问，工具调用也发生在用户电脑上，用户能清楚知道工具在操作什么。MCPServer同样运行在本地，用户能评估其安全性。总之，用户对数据安全有完全把控。

现在MCP协议被推广到服务端，很多后台服务的智能体框架都在使用MCP协议。这带来了一定的安全隐患。

一旦工具调用由服务器接管，所有用户都在调用同一服务，用户身份和数据安全问题就变得复杂了。所以，我始终认为MCP是个不错的客户端协议，但它可能并不适用于服务端场景。

另外，大火的Manus在工具调用上也没用MCP，而是传统的FunctionCall。
在spring-ai这个开源智能框架里，对MCP的支持不过是把MCP的工具描述转化成OpenAI格式的tools节点，本质上还是FunctionCall。

XML Tags VS JSON

目前，只有Cline这个智能编码助手采用XML结构描述MCP工具，而非OpenAI的tools节点（JSON格式）。它通过将工具描述嵌入系统提示词并自定义XML解析方法，让模型输出XML格式的工具调用后触发实际工具实现。

此举解决了部分大模型不支持FunctionCall的问题，又屏蔽了底层模型的差异。

最近一项研究发现，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的一个关键特性是，其主智能体可以通过调用工具动态调整任务清单。这一设计非常出色，也契合了我长期坚持的理念：只有当智能体能够自主管理任务时，它才能真正模拟人类的工作方式——根据实际情况灵活调整任务安排。

包括很多智能体都有任务，下图为京东的开源智能体框架。

以及360的纳米搜索也支持任务分解。

02 决定智能体表现的关键：系统提示词

随着对智能体研究的深入，我愈发认识到系统提示词的编写直接决定了智能体的表现。

许多开发者因缺乏系统性指导，仅凭个人感觉编写提示词，导致内容过于基础。当使用能力较强的大模型时，即便提示词较为简单，智能体也能较好地遵循指令；然而，若选用的模型能力有限，智能体的表现就会大打折扣，甚至难以完成基本任务。

这充分说明，提示词的编写是一门需要技巧的专业工作。

ClaudeCode 提示词赏析

我们先来解读一下ClaudeCode的提示词（中文翻译版），它的设计非常巧妙：

你是 Claude Code，Anthropic 官方推出的 Claude 命令行界面（CLI）。
你是一个交互式 CLI 工具，帮助用户完成软件工程任务。请使用以下说明和你可用的工具来协助用户。
重要提示：仅协助处理防御性安全任务。拒绝创建、修改或改进可能被恶意利用的代码。允许进行安全分析、制定检测规则、解释漏洞、使用防御性工具和编写安全文档。 重要提示：你绝不能为用户生成或猜测 URL，除非你确信这些 URL 是用于帮助用户编程的。你可以使用用户在其消息或本地文件中提供的 URL。
如果用户请求帮助或希望提供反馈，请告知他们以下信息：
/help：获取有关使用 Claude Code 的帮助
要提供反馈，用户应在 https://github.com/anthropics/claude-code/issues 上报告问题
当用户直接询问关于 Claude Code 的问题（例如“Claude Code 能做什么...”、“Claude Code 有没有...”）或以第二人称提问（例如“你能不能...”、“你能做...”）时，请首先使用 WebFetch 工具从 Claude Code 的官方文档 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 中的相关文件以找出如何监视文件] npm run dev </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 和类型检查命令（例如 npm run lint、npm run typecheck、ruff 等），你必须使用 Bash 运行它们，以确保你的代码是正确的。如果你找不到正确的命令，请向用户询问要运行的命令，如果他们提供了，请主动建议将其写入 CLAUDE.md，以便你下次知道要运行它。 除非用户明确要求，否则绝不提交更改。非常重要的一点是，只有在明确要求时才提交，否则用户会觉得你过于主动。
工具结果和用户消息可能包含 <system-reminder> 标签。<system-reminder> 标签包含有用的信息和提醒。它们不是用户提供的输入或工具结果的一部分。
工具使用政策
在进行文件搜索时，优先使用 Task 工具以减少上下文使用。
当手头的任务与专业代理的描述相匹配时，你应该主动使用带有这些专业代理的 Task 工具。
当 WebFetch 返回有关重定向到不同主机的消息时，你应该立即使用响应中提供的重定向 URL 发出新的 WebFetch 请求。
你有能力在单个响应中调用多个工具。当请求多个独立的信息时，将你的工具调用批处理在一起以获得最佳性能。当进行多个 bash 工具调用时，你必须发送一个包含多个工具调用的单一消息以并行运行这些调用。例如，如果你需要运行 "git status" 和 "git diff"，请发送一个包含两个工具调用的单一消息以并行运行这些调用。
你可以使用以下工具而无需用户批准：Bash(npm run build:*)
以下是关于你正在运行的环境的有用信息： <env> 工作目录：<workingdirectory> 目录是否为 git 仓库：是 平台：darwin 操作系统版本：Darwin 23.6.0 今天的日期：2025-08-19 </env> 你由名为 Sonnet 4 的模型提供支持。确切的模型 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建模的提示词，网上流传的比较不错的版本。

turn this photo into a character figure. Behind it, place a box with the character’s image printed on it, and a computer showing the Blender modeling process on its screen. In front of the box, add a round plastic base with the character figure standing on it. Make the PVC material look clear, and set the scene indoors if possible.

模型效果与训练资料和方向息息相关

模型的能力与其训练数据密切相关。

以大学专业为例：计算机专业的学生自然对计算机术语了如指掌，财务专业的学生则熟悉财务术语。

这同样解释了为什么Claude的自研产品配合自家模型能达到最佳效果，而ClaudeCode换用其他模型时表现就会下降。即便是经过自己训练的模型，也会更贴合使用者的需求。这说明Claude的提示词是经过特殊设计的，专门为了最大化发挥其自研模型的性能。

对于业务的理解决定不同人开发智能体的水平

普通人使用AI的门槛其实在于：清楚自己想要什么，却不知如何描述。

多数人的提问停留在"帮我整理表格"、“写份报告"这种模糊层面，但核心问题在于——你需要什么样的具体结果？就像描述一个人需要"高矮胖瘦”、"年龄性格"等无数参数，面对陌生领域时，我们往往缺乏描述所需的词汇。

因此，写出优秀提示词的前提是先了解相关领域。只有真正理解自己想要什么，才能引导模型输出满意的结果。

智能体开发人员要深刻理解业务，同时要精通提示词的结构

作为智能场景的开发人员，你必须清楚：你的智能场景在做什么、如何运作，以及智能体的处理流程。

这包括智能体真正需要的知识和工具，以及动态上下文该如何组织。这些内容最终都会封装进调用大模型的请求体中，引导模型做出下一步响应。

目前业界推崇的"上下文工程"，正是将提示词进行精细化分类，划分为不同部分进行准确描述。由此可见，提示词编写并非易事，而是一项精细活儿。

不过，随着你对业务理解的深入和对模型"性格"的把握，你的提示词效果会越来越好。

今天的分享到这就结束了，点个赞再走吧。

欢迎大家积极留言共建，期待与各位技术大咖的深入交流！

此外，欢迎大家下载我们的inBuilder低代码社区，可免费下载使用，加入我们，开启开发体验之旅！