51c大模型~合集181
我自己的原文哦~ https://blog.51cto.com/whaosoft/14174584
#LLaDA-MoE
扩散语言模型也有MoE版本了！蚂蚁&人大从头训练LLaDA-MoE，即将完全开源
挑战自回归的扩散语言模型刚刚迎来了一个新里程碑：蚂蚁集团和人大联合团队用 20T 数据，从零训练出了业界首个原生 MoE 架构扩散语言模型 LLaDA-MoE。该模型虽然激活参数仅 1.4B，但性能可以比肩参数更多的自回归稠密模型 Qwen2.5-3B，而且推理速度更快。这为扩散语言模型的技术可行性提供了关键验证。
万万没想到，做奥数题都能拿金牌的模型，却不会「倒着背诗」。
说完全不会，倒也不严谨。因为如果允许模型「深度思考」，给诗的每个字都编上号，然后倒着排一下，这诗也能背出来。然而，这与人类倒背文本的方式并不一样 —— 人类记忆诗词时，往往不是逐字死记，而是以句子、意境、节奏为单位，而倒背时则是在脑中「反向调用」这些单元。
研究者们在 2023 年的一篇论文中就提到了这个现象，并将其命名为「Reversal Curse（反转诅咒）」。类似的表现还包括模型学习了「A is B（如巴黎是法国的首都）」之后，却无法自然地推出「B is A（如法国的首都是哪里）」。
这个问题之所以被拎出来讨论，是因为它会在一些需要模型同时理解前后文或逆向推理的场景中影响性能。
两年过去，AI 大模型能力突飞猛进，但这一问题始终没有得到本质上的解决。究其原因，这是当前大模型普遍采用的自回归（AR）生成范式所造成的 —— 模型天然是单向建模的，从前往后依次生成下一个 token。这导致它们难以捕捉 token 之间的双向依赖关系。
而且，自回归的天然缺陷还不止这一个 —— 长文本的计算成本高、生成速度慢是常被诟病的问题，而且它缺乏直接修正错误的能力，还会导致错误产生连锁反应。
面对这些问题，大量研究者选择继续改进自回归，但也有人另辟蹊径，尝试新的建模范式。
蚂蚁集团和中国人民大学高瓴人工智能学院组成的联合研究团队选择的就是后者，他们探索的语言建模方向是「扩散（diffusion）」。
在他们之前，也有不少研究者在这一方向发力。但今年 2 月份，他们首次将扩散语言模型（dLLM）扩展至 8B 参数规模，推出了性能对标 LLaMA 3 的 LLaDA 模型。
自回归模型的生成方式。
LLaDA 模型的生成方式。
LLaDA 一经发布就引起了广泛关注，因为它通过非自回归的掩码扩散机制，首次在大规模语言模型中实现了与自回归模型相当的语言智能（如上下文学习、指令遵循、多轮对话等），挑战了「语言模型必须自回归」的主流认知。
在过去的几个月里，LLaDA 系列一直在快速迭代，衍生出了对齐能力更强的 LLaDA1.5、多模态版本的 LLaDA-V，以及刚刚在外滩大会上亮相的 LLaDA-MoE。
其中，LLaDA-MoE 尤为引人注目。它由蚂蚁集团通用人工智能研究中心和人民大学联合研发，是业界首个从零训练的原生 MoE 架构扩散语言模型，在 20T 的数据上完成了训练，验证了此类模型大规模训练的可扩展性和稳定性。
在效果上，它不仅超过了此前发布的稠密扩散语言模型 LLaDA1.0/1.5 和 Dream-7B，更是以 1.4B 激活参数比肩稠密自回归模型 Qwen2.5-3B，并保有数倍的推理速度优势。
可以说，LLaDA-MoE 是 dLLM 发展历程中的又一个重要里程碑。
据悉，该模型将在近期完全开源，以推动全球 AI 社区在扩散语言模型上的技术发展。
这个模型具体表现如何？背后有哪些技术？为什么这类模型能 work？在发布会之后的一次访谈中，蚂蚁通用人工智能研究中心主任蓝振忠、中国人民大学高瓴人工智能学院副教授李崇轩透露了很多细节，我们将在本文中一一介绍。
左：李崇轩；右：蓝振忠。
LLaDA-MoE
业界首个从零训练的原生 MoE 架构扩散语言模型
经过 3 年多的迭代，dLLM 的发展已经进入成熟期。尤其在 LLaDA 模型发布之后，大家真正看到了这一类模型的可用性。很多研究已经把 LLaDA 作为基础或主干模型来进行进一步微调或扩展。
不过，要想提升模型能力上限，dLLM 同样必须进一步 scaling。而从自回归的发展路径来看，这一目标可以借助 MoE 来实现。
对于蚂蚁和人大的联合团队来说，这又是一条未知的路，因为现有的扩散语言模型探索都是基于稠密架构，与 MoE 相关的预训练、后训练甚至推理都存在大量未知的难题。而且 MoE 本身就比较难训练，在扩散这个新架构上做 MoE 则更加困难。
不过，蓝振忠表示，真正去做了之后，他们发现这些「风险」其实都是可管理的。这很大程度上是因为，他们有一些关键的工程、资源积累可以依托：
首先是一些已经在自回归模型上验证过的 MoE 训练经验和技术积累 —— 无论是业界开源的还是蚂蚁自身的经验，其实很多都可以拿来复用，这帮助他们解决了一些诸如负载均衡、噪声采样 shift 之类的问题。
其次是高质量的数据基础。团队直接复用了蚂蚁百灵大模型积累的 20T 数据，节省了大量人力物力。
最后是完善的工程基础设施。蚂蚁自研的 ATorch 训练框架已经具备专家并行（EP）等一系列并行加速技术，能够为大规模 MoE 训练提供强有力的技术支撑。同时，蚂蚁算力集群的稳定性确保了 20T 数据量级别的工业级训练能够高效稳定完成。
正是基于这些关键积累，团队最终成功打造出了 LLaDA-MoE。这是一个总参数量为 7B 的模型，激活参数量为 1.4B。目前，LLaDA-MoE 有两个版本：基础模型版 LLaDA-MoE-7B-A1B-Base 和指令微调版 LLaDA-MoE-7B-A1B-Instruct。
- HuggingFace 链接：https://huggingface.co/inclusionAI/LLaDA-MoE-7B-A1B-Base
- GitHub 链接：https://github.com/ML-GSAI/LLaDA
在各项 benchmark 测试中，LLaDA-MoE 超越了现有的开源稠密 dLLM 模型，如 LLaDA1.0/1.5 和 Dream-7B，在代码、数学、Agent 这类相对结构化的任务上优势明显。此外，模型效果也追平了 Qwen2.5-3B 这个用同样数据量训练的稠密自回归模型，由此实现了 1.4B 激活参数，达到 2 倍多参数稠密模型的等效比。这说明 MoE 架构性能放大器的作用在 dLLM 上也成立。团队表示，他们后续将继续挖掘等效比这个 scaling law，探索更高稀疏比、更大尺寸的 MoE 扩散语言模型，以进一步释放 LLaDA-MoE 的规模化潜力。
同时，他们还在 dLLM 推理加速方面持续投入，针对 dLLM 的并行特性，从算子融合、计算图优化、并行加速、缓存管理、并行解码等多个方面进行了全面优化，相比开源 SOTA 的 NVIDIA fast-dLLM 推理引擎实现了显著加速。相关代码与技术报告也将于近期开源、公布，以助力 dLLM 技术的快速发展。
扩散语言模型
为什么能 work？
在蓝振忠、李崇轩看来，dLLM 能走到今天，有一定的必然性，因为无论从底层理论还是实践经验来看，这个方向都有着巨大的潜力。
首先，从理论上来看，李崇轩指出：从概率建模的角度来看，大语言模型的关键并不是必须依赖自回归展开，而是能否有效地表示和学习高维复杂的联合概率分布，即通过最大似然估计或最小化 KL 散度来逼近真实语言分布。
自回归的优势在于通过链式法则把难以直接建模的联合概率分解为逐步的条件概率，从而简化了训练和优化过程，但这种方式并不是唯一的。扩散模型提供了另一条路径：它不依赖固定的从左到右生成顺序，而是通过迭代的去噪过程逐渐逼近数据分布，这种过程同样能够刻画高维概率，只是采取了「由粗到细」的动态修正方式。
李崇轩特别指出，很多人们认为是自回归独有的性质，比如指令跟随、In-context Learning、压缩能力和可扩展性，其实更深层次上都源于最大似然估计这一共同的学习准则，而不是自回归本身。
例如，条件概率建模赋予模型指令跟随和对话能力，信息论意义上的最大似然保证了压缩特性，而优化的简洁性和与 Transformer 架构的兼容性则保证了可扩展性。这些性质同样可以在扩散模型里出现。
与此同时，自回归范式也存在固有局限：完成时间与输出长度成正比、只能单向展开、缺乏直接修正错误的能力。而扩散模型在这些方面提供了潜在优势，它天然支持并行解码、双向建模和迭代修正：
- 并行解码意味着生成过程不必逐 token rollout，而是可以在有限步数内同时更新多个位置，使得推理迭代次数与输出长度不再严格挂钩，在长文本场景下更具效率潜力。此外，这种并行性还有望带来算力利用率的提升。传统自回归推理由于串行瓶颈，往往导致 GPU 大量算力处于空闲状态；而扩散模型的并行更新方式则能够在每一次迭代中充分调动大规模矩阵运算，更好地发挥硬件性能，从而在单用户使用时也能保持较快的响应速度，避免了自回归推理那种因为缺乏并发而浪费算力的情况。
- 双向建模让模型能够同时利用前后文信息来重构序列，从而提升全局一致性和逻辑连贯性，在图文并茂等没有严格从前到后顺序的多模态场景中也更加自然。
- 迭代修正则带来灵活的交互方式：当输出中某一部分有错误或需要修改时，扩散模型可以只针对局部片段重新采样，而不必推倒重来。这种能力尤其适合代码生成、文档编辑等需要频繁调整的场景。
此外，有证据表明，在同样的数据量下，扩散语言模型的学习效果比自回归模型更好。具体表现为，在有限数据场景中，自回归模型往往在几轮数据复用之后便迅速进入收益递减阶段，而扩散模型则能够持续从重复数据中榨取增量信息（dLLM 的数据利用效率可以达到 AR 的 3 倍以上）；即便在极端重复的条件下，dLLM 依然能够不断提升在下游任务中的能力。
这种「榨干」数据的能力和 dLLM 的双向建模机制密切相关。传统的自回归模型采用严格的因果性建模方式，每个 token 的预测只能基于前面的 token，这种单向的信息流限制了模型对数据中复杂依赖关系的捕获。而 dLLM 通过掩码机制实现了真正的双向建模，允许模型在任意顺序下理解和生成文本。
从技术层面看，扩散模型的训练目标本身就要求对每个数据点进行多种不同的掩码配置和比例的处理。这意味着每次重复同一份数据时，模型实际上是在学习该数据的不同「视角」—— 不同的掩码模式暴露了数据中不同的上下文依赖关系。相比之下，自回归模型在重复训练时只是在强化相同的从前到后的预测模式。
这种数据效率优势在当前 AI 发展阶段具有特殊意义。随着高质量预训练数据逐渐稀缺，而计算资源变得相对充裕，用更多计算换取更好的数据利用率成为了一个合理的权衡。扩散语言模型虽然在训练和推理时需要消耗更多 FLOPs，但这种「超密度计算」带来的智能提升可能是值得的。
在 LLaDA 系列模型的研究中，蚂蚁和人大的联合团队已经验证了扩散语言模型的一些理论优势和工程可行性，让这个充满「不确定」的方向逐渐变得清晰、明朗起来。但要想充分兑现这一方向的潜力，他们还有很多问题需要克服，比如如何把理论上的速度优势在工程中真正实现，如何把模型 scale 到更大规模，如何设计类似 KV cache 的缓存机制，如何解决可变长度问题等。随着 LLaDA 系列模型的开源，这些问题有望借助社区的力量来共同解决。
「这个方向需要更多聪明的人参与进来，就像自回归模型的发展依靠了全世界的贡献，扩散语言模型的发展同样需要借助社区的力量。」蓝振忠在采访中说到。
跳出常规思维
探索智能上限
在谈到打造 LLaDA-MoE 的难点时，李崇轩提到：其实最难的一点是「下决心」，因为这件事没有人做过，「大家不知道能不能成」。
谈到这个「下决心」的过程，蓝振忠表示：「如果你不去探索那些在别人眼中可能充满风险的领域，我们就只能永远跟随他人已经确定的路径前行。我们要提升智能的上限，就不能一直 follow。」
当然，这种冒险是建立在理性判断的基础上。正如前文所言，在理论研究和实践的过程中，团队逐渐确信：扩散语言模型是一个有希望落地且风险可控的方向，而且在提升智能上限方面非常有潜力。因此，当他们真正决定投入资源去构建 LLaDA-MoE 时，这不仅是一次技术上的尝试，更是一次主动打破路径依赖、以不确定性换取未来上限的战略性选择。
能做出这种战略选择，对蚂蚁来说不是偶然。对这种前瞻性方向的判断和大力投入，在蚂蚁也有先例，比如百灵大模型的开源，推理框架 AReaL、多智能体框架 AWorld 的布局等等。
此外，蓝振忠所领导的通用人工智能研究中心还在向其他前沿方向发力，比如动态 MoE 架构的创新、混合线性架构的探索等。
这些方向全都围绕一个「北极星」指标 —— 通用人工智能（AGI）。他们希望通过不断的创新，把智能推到一个新高度。
我们也希望看到他们在这一方向取得更多进展。
参考链接
https://jinjieni.notion.site/Diffusion-Language-Models-are-Super-Data-Learners-239d8f03a866800ab196e49928c019ac#244d8f03a866808fb358d7a97bbd26f2
..
#writing-tools-for-agents
如何为LLM智能体编写工具？Anthropic官方教程来了
好工具，才有好智能体。
智能体（Agent）时代，工具已不再只是传统 API 或函数接口的简单封装，而是决定智能体能否高效完成任务的关键。
为了让智能体真正释放潜力，我们需要重新思考工具开发的方式。传统软件开发依赖确定性逻辑，而智能体是非确定性的，它们在相同输入下可能产生不同输出，这意味着为智能体设计工具需要新的范式。
而新的范式不仅仅是如何开发工具，更在于如何让工具真正发挥最大效能。毕竟，AI 智能体的强大程度取决于我们为其提供的工具，但问题是：如何让这些工具发挥最大效能？
来自 Anthropic 的一篇文章为大家指出了一条可行路径。
原文链接：https://www.anthropic.com/engineering/writing-tools-for-agents
以下是博客内容：
在这篇文章中，Anthropic 介绍了一些在多种 agentic AI 系统中被证明最有效的性能提升技巧。
阅读本文后，你可以做到：
- 构建并测试工具原型；
- 如何创建并运行全面的评估；
- 与智能体协作（如 Claude Code），自动提升模型性能。
工具的定义
在计算机中，确定性系统在给定相同输入时，每次都会产生相同的输出；而非确定性系统，比如智能体，即便在相同的初始条件下，也可能生成不同的响应。
在传统的软件开发中，我们是在确定性系统之间建立契约。例如，一个关于天气的函数调用 getWeather ("NYC")，无论调用多少次，都将以完全相同的方式返回纽约的天气。
而基于大模型的工具是一种全新的软件形式，它体现的是确定性系统与非确定性智能体之间的契约。
举个例子：当用户问「我今天要带伞吗？」时，智能体可能会调用天气工具、也可能直接基于常识回答，甚至先提出一个澄清性问题（比如确认具体地点）。有时，智能体还可能出现幻觉，或者根本没弄明白该如何使用工具。
这意味着，我们在为智能体编写软件时，必须从根本上重新思考方法：不能再把工具和 MCP 服务器当作普通函数或 API 来写，而是需要专门为智能体设计。
那如何设计工具呢？
如何编写工具？
首先，快速搭建工具原型并在本地进行测试。
接着，进行全面评估来衡量后续改动带来的影响。
在与智能体协作的过程中，你可以不断重复评估与改进这一循环，直到智能体能够在现实任务中表现出强劲的性能。
构建原型
在该教程中，我们以基于 Claude 的智能体构建为例。
如果你使用 Claude Code 来编写工具，最好向 Claude 提供相关的文档，例如工具依赖的软件库、API 或 SDK（包括可能用到的 MCP SDK）。
另外，适合 LLM 阅读的文档通常可以在官方文档网站上以 llms.txt 文件的形式找到，大家可以自行下载。
你也可以将工具封装在本地 MCP 服务器或桌面扩展程序 (DXT) 中，即可在 Claude Code 或 Claude Desktop 应用中连接并测试这些工具。
值得一提的是，如果你要将本地 MCP 服务器连接到 Claude Code，请运行 claude mcp add <name> <command> [args...]。
此外，要将本地 MCP 服务器或 DXT 连接到 Claude Desktop 应用，请分别前往「设置”>“开发者” 或 “设置”>“扩展程序”」。你也可以将工具直接传入 Anthropic API 调用进行编程测试。
这些做完之后，还要自行测试以发现不足之处。
运行评估
接下来，你需要通过评估来衡量工具的效果。
评估可以分为几个部分进行，首先是生成评估任务。
在你完成早期原型后，Claude Code 可以检验你的工具，并生成数十组提示与响应对。
这些提示应当源自真实的使用场景，并基于真实的数据源和服务（例如内部知识库和微服务）。
- 本文建议避免使用过于简单或太过于表面的沙盒环境，因为那样无法在足够复杂的条件下对工具进行压力测试。
- 那些高质量的评估任务往往需要多次工具调用，甚至可能多达数十次。
那什么是好的任务评估呢？大家可以参考如下示例：
- 安排下周与 Jane 会面，讨论我们最新的 Acme Corp 项目。附上我们上次项目规划会议的记录，并预订会议室。
- 客户 ID 9182 报告称，他们单次购买被扣款三次。查找所有相关日志条目，并确定是否有其他客户受到同一问题的影响。
- 客户 Sarah Chen 刚刚提交了取消订单的申请。准备一份留任方案。确定：(1) 他们离开的原因；(2) 哪种留任方案最具吸引力；以及 (3) 在提出方案之前我们应该注意的风险因素。
还有一些较弱的任务：
- 安排下周与 jane@acme.corp 的会议。
- 在付款日志中搜索 purchase_complete 和 customer_id=9182。
- 查找客户 ID 为 45892 的取消请求。
每个评估 prompt 都应与可验证的响应或结果配对。你设置的验证器可以简单到只是在基本事实和采样响应之间进行精确的字符串比较，也可以高级到请大模型来判断响应。避免使用过于严格的验证器，因为这些验证器会因为格式、标点符号或有效的替代措辞等虚假差异而拒绝正确的响应。
对于每个提示 - 响应对，你还可以选择指定智能体在解决任务时调用的工具，以衡量智能体在评估过程中是否成功掌握了每个工具的用途。但是，由于正确解决任务可能存在多种有效途径，因此请尽量避免过度指定或过度拟合策略。
接着是运行评估。
本文建议通过直接调用 LLM API 以编程方式运行评估。
还可以采用简单的智能体循环（例如用 while 循环交替包装 LLM API 与工具调用）：每个评估任务对应一个循环。每个评估智能体应被分配一个任务提示和相关工具。
如果你使用 Claude 运行评估，可以直接启用 interleaved thinking（交错思维）。这样一来你就能探究智能体为何调用或不调用某些工具。
在评估过程中，除了准确率，本文还建议收集智能体的其他指标，例如：
- 单次工具调用和任务的总运行时间；
- 工具调用总次数；
- 总 token 消耗；
- 工具错误情况。
接下来是结果分析。
通常来讲，有时智能体在反馈和回答中遗漏的内容，往往比它们提到的内容更重要。LLM 并不总是准确表达出它们的真实含义。
你需要观察智能体在什么地方会卡住或感到困惑。我们需要根据反馈，定位工具的薄弱环节。
与此同时，我们需要回顾原始对话记录（包括工具调用和工具响应），以捕捉那些没有明确出现在智能体 CoT 中的行为。记住评估智能体并不一定真正知道正确答案或最佳策略。
另外，还需要分析你的工具调用指标：
- 冗余调用过多 → 可能说明需要重新设计分页或 token 限制参数；
- 无效参数导致的错误过多 → 可能说明工具需要更清晰的描述或更好的使用示例。
用户还可以与智能体协作。
你甚至可以让智能体直接帮你分析结果并改进工具。
只需将评估智能体的对话记录拼接起来，然后粘贴到 Claude Code 中即可。Claude 擅长分析对话记录，并能一次性重构大量工具。
如何编写高效工具？有哪些原则
选择合适的工具
并不是说工具越多，结果就越好。我们观察到一个现象：工具只是简单封装了现有软件功能或 API 接口，而很多时候调用这些工具是否真正适合智能体还未知。
原因在于，智能体与传统软件有着不同的可供性（affordances），也就是说，它们感知并使用工具的方式与传统软件截然不同。
- 举个例子：LLM 智能体的上下文有限（即一次能处理的信息量有限），而计算机内存廉价且几乎无限。
- 在地址簿中查找联系人这个任务上，传统软件可以高效地逐个存储并处理联系人，检查完一个再检查下一个。
然而，如果一个 LLM 智能体使用的工具返回了所有联系人，并且必须逐个 token 地读完，那么它就会把有限的上下文空间浪费在无关信息上。（想象一下，在地址簿里找联系人时，你得从头到尾一页一页翻阅，这其实就是一种暴力搜索。）
更好、更自然的方式（无论对智能体还是对人类而言）都是直接跳到相关页面（比如按字母顺序定位）。
因此，本文建议先构建少量经过深思熟虑的工具，针对高价值的工作流，并与评估任务保持一致，然后再逐步扩展。在地址簿的例子中，你可以实现一个 search_contacts 或 message_contact 工具，而不是简单地提供一个 list_contacts 工具。
此外，工具还有整合能力，能在底层同时处理多个离散操作（或 API 调用）。
例如，工具可以：
- 在返回结果时附加相关元数据；
- 或者在一次调用中完成经常需要串联的多步任务。
以下是整合功能的一些示例：
- 与其分别实现 list_users、list_events 和 create_event 工具，不如实现一个 schedule_event 工具，它可以查找空闲时间并能直接安排其他任务。
- 与其实现一个 read_logs 工具，不如实现一个 search_logs 工具，它只返回相关的日志行以及必要的上下文。
- 与其实现 get_customer_by_id、list_transactions 和 list_notes 工具，不如实现一个 get_customer_context 工具，它能一次性汇总某个客户的所有近期且相关的信息。
所以说，你构建的每个工具都应当具有清晰且独立的目标。工具应当使智能体能够像人类一样，在获取相同底层资源的情况下，去分解并解决任务，同时还能减少原本会被中间结果消耗掉的上下文空间。
过多的工具或功能重叠的工具，反而会分散智能体的注意力，阻碍其选择高效的策略。
因此，谨慎且有选择性地规划哪些工具需要构建（或不需要构建），往往会带来更大的回报。
为工具设置命名空间
AI 智能体可能会接入数十个 MCP 服务器和数百个不同的工具，其中还包括其他开发者编写的工具。
当工具在功能上出现重叠，或者用途模糊不清时，智能体就可能会混淆该用哪个工具。
命名空间（即给相关工具加上统一前缀分组）可以划清不同工具之间的边界；有些 MCP 客户端会默认采用这种方式。
例如，可以按服务进行命名空间划分（如 asana_search、jira_search），也可以按资源划分（如 asana_projects_search、asana_users_search），这样能够帮助智能体在合适的时机选择正确的工具。
本文发现，前缀式命名和后缀式命名在工具使用评估中的效果并不相同。本文建议根据你的评估结果来选择合适的命名方式。
假如不这样做的话，智能体可能会：
- 调用错误的工具；
- 或者用错误的参数调用正确的工具；
- 又或者调用的工具太少；
- 甚至错误地处理了工具响应。
从工具中返回有意义的上下文
同样，工具实现应注意仅向智能体返回高信号信息。它们应优先考虑上下文相关性而非灵活性，并避免使用低级技术标识符（例如：uuid、256px_image_url、mime_type）。诸如 name、image_url 和 file_type 之类的字段更有可能直接影响智能体的下游操作和响应。
智能体处理自然语言名称、术语或标识符的能力也显著优于处理隐晦的标识符。实践发现，仅仅将任意字母数字 UUID 解析为语义上更有意义且更易于解释的语言（甚至是 0 索引的 ID 方案）就能显著提高 Claude 在检索任务中的准确率，从而减少幻觉。
在某些情况下，智能体可能需要灵活地与自然语言和技术标识符输出进行交互，哪怕只是为了触发下游工具调用（例如，search_user (name=’jane’) → send_message (id=12345)）。你可以通过在工具中公开一个简单的 response_format 枚举参数来启用这两种功能，从而允许智能体控制工具返回「简洁」还是「详细」的响应（如下图所示）。
你可以添加更多格式以获得更大的灵活性，类似于 GraphQL，也可以精确选择要接收的信息。以下是一个用于控制工具响应详细程度的 ResponseFormat 枚举示例：
enum ResponseFormat {DETAILED = "detailed",CONCISE = "concise"
}以下是详细工具响应的示例（206 个 token）：
以下是一个简洁工具响应（72 个 token）的示例：
Slack 线程和线程回复由唯一的 thread_ts 标识，这些 thread_ts 是获取线程回复所必需的。thread_ts 和其他 ID（channel_id、user_id）可以从「详细」工具响应中检索，以便后续需要这些 ID 的工具调用。「简洁」工具响应仅返回线程内容，不包含 ID。本例中使用约 1/3 个 token 作为「简洁」工具响应。
你的工具响应结构（例如 XML、JSON 或 Markdown）也会对评估性能产生影响：没有一刀切的解决方案。这是因为 LLM 是基于下一个 token 预测进行训练的，并且往往在使用与其训练数据匹配的格式时表现更佳。最佳响应结构会因任务和智能体而异，建议根据自身的评估选择最佳响应结构。
优化工具响应以提高 token 效率
优化上下文质量至关重要。但优化工具响应中返回给智能体的上下文数量也同样重要。
Anthropic 建议，对于任何可能消耗大量上下文的工具响应，结合分页、范围选择、过滤和 / 或截断功能，并设置合理的默认参数值。对于 Claude Code 来说，工具响应限制默认是 25000 个 token。未来智能体的有效上下文长度会随着时间的推移而增长，但对上下文高效工具的需求会始终存在。
如果你选择截断响应，请务必为智能体提供实用的指导。你可以直接鼓励智能体采用更高效的 token 策略，例如，在知识检索任务中进行多次小规模、有针对性的搜索，而不是进行单一、广泛的搜索。同样，如果工具调用引发错误（例如，在输入验证期间），你可以对错误响应进行提示式设计，以清晰地传达具体且可操作的改进措施，而不是使用晦涩难懂的错误代码或回溯。
以下是截断工具响应的示例：
以下是一个无用的错误响应示例：
以下是一个有用的错误响应示例：
快速构建工具描述
现在来谈谈改进工具的最有效方法之一：快速构建工具描述和规范。由于这些内容会加载到智能体的上下文中，因此它们可以共同引导智能体实现有效的工具调用行为。
在编写工具描述和规范时，请思考如何向团队中的新成员描述你的工具。考虑到可能隐式引入的上下文 —— 专用查询格式、专业术语的定义、底层资源之间的关系 —— 并将其明确化。通过清晰描述（并使用严格的数据模型强制执行）预期的输入和输出，避免歧义。特别是，输入参数的命名应清晰明确：不要使用名为 user 的参数，而应尝试使用名为 user_id 的参数。
通过评估，你可以更有信心地衡量快速构建的影响。即使对工具描述进行微小的改进，也能带来显著的提升。在对工具描述进行精准改进后，Claude Sonnet 3.5 在 SWE-bench Verified 评估中取得了最佳性能，大幅降低了错误率，并提高了任务完成率。
展望未来
为了构建高效的智能体工具，我们需要重新调整软件开发实践，从可预测的确定性模式转向非确定性模式。
通过本文中描述的迭代式、评估驱动的流程，现在已经出现了使工具成功的一致模式：高效的工具应具有清晰明确的定义，能够合理地利用智能体上下文，能够在不同的工作流程中组合使用，并支持智能体直观地解决现实世界中的任务。
Anthropic 预计，智能体与世界交互的具体机制将不断演变 —— 从 MCP 协议的更新到底层 LLM 本身的升级。通过系统化的、评估驱动的方法来改进智能体工具，我们可以确保随着智能体能力的提升，它们所使用的工具也能随之发展。
..
#Youtu-GraphRAG
腾讯优图重磅开源Youtu-GraphRAG，实现图检索增强技术新突破
图检索增强生成（GraphRAG）已成为大模型解决复杂领域知识问答的重要解决方案之一。然而，当前学界和开源界的方案都面临着三大关键痛点：
- 开销巨大：通过 LLM 构建图谱及社区，Token 消耗大，耗时长，经济与时间成本高昂。
- 效果瓶颈：对复杂问答的解析精度有限，面临显著的效果瓶颈。
- 适配成本高：缺乏跨任务泛化能力，遇新领域需重新调整全链路，迁移成本高。
针对这些难题，腾讯优图实验室正式开源 Youtu-GraphRAG 框架，通过创新的算法优化，实现了成本和效果的双重突破！
- 论文标题：Youtu-GraphRAG: Vertically Unified Agents for Graph Retrieval-Augmented Complex Reasoning
- 论文链接：https://arxiv.org/pdf/2508.19855
成本和效果的双重突破
在六个跨领域多语言基准测试中，Youtu-GraphRAG 展现出卓越性能：
- 大幅成本优化：相比同类最佳方案，构图成本节省 30%+；
- 显著精度提升：在复杂推理任务中获得最高 16%+ 的准确率提升；
这些结果标志着 GraphRAG 技术向落地可用的发展阶段迈进了重要的一步。
技术架构：三大创新构建垂直统一的完整方案
Youtu-GraphRAG 通过 Schema 连接两个智能体，在图构建、索引和检索上实现垂直统一和认知闭环，以领先的落地级图构建与推理能力推动 GraphRAG 进入新的阶段。
1. Schema 引导的层次化知识树构建
通过引入有针对性的实体类型、关系和属性类型，为图构建智能体提供精确约束，实现了跨领域知识的自主演化和高质量抽取。四层架构设计包括：
- 属性层：存储实体的属性信息
- 关系层：构建实体间的关系三元组
- 关键词层：建立关键词索引体系
- 社区层：形成层次化的高维度社区结构
2. 结构语义双重感知的社区检测
巧妙融合结构拓扑特征与子图语义信息，在复杂网络中提炼高维度知识加强推理总结能力，社区生成效果显著优于传统 Leiden 和 Louvain 算法。利用大模型进行社区摘要生成，实现更高层次的知识抽象。
3. 智能迭代检索机制
深度理解图 Schema，将复杂查询针对性地转换为符合图特征且可并行处理的子查询，通过迭代检索进一步提升思维链追溯与反思能力。
When & Why? 三大核心应用场景
多跳推理与总结
完美解决需要多步推理的复杂问题，如深度关联分析、因果推理等场景。
知识密集型任务
高效处理依赖大量结构化知识的问题，如企业知识库问答、技术文档深度解析。
跨域扩展应用
轻松支持学术论文、个人知识库、私域 / 企业知识库等多个领域，最小化人工干预成本。
交互界面
快速启动：四步开箱智能复杂问答
第一步：获取项目代码
git clone https://github.com/TencentCloudADP/youtu-graphrag
cd youtu-graphrag第二步：环境配置
1. 首先访问提供模型服务的平台，获取远程调用模型的凭证 API key。
2. 按照.env.example 格式创建配置文件，创建并复制 API key，`Youtu-GraphRAG` 项目的 `.env` 文件中的 llm 部分中设置。
cp .env.example .env
# 配置 OpenAI 格式的 LLM API
# LLM_MODEL=deepseek-chat
# LLM_BASE_URL=https://api.deepseek.com
# LLM_API_KEY=sk-xxxxxx第三步：一键部署
docker build -t youtu_graphrag:v1 .
# 启动 docker 容器
docker run -d -p 8000:8000 youtu_graphrag:v1第四步：体验交互
curl -v http://localhost:8000访问 http://localhost:8000 即可体验完整的图增强推理服务，包括：
- 可视化知识图谱展示
- 交互式智能问答
- 实时推理路径追踪
企业级优势特性
统一配置管理
- 集中化参数管理：所有组件通过单一 YAML 文件统一配置
- 多环境无缝支持：轻松实现跨领域迁移部署
高性能架构
- 并行子问题处理：采用并行机制处理分解后的问题
- 迭代推理演进：逐步构建答案，提供清晰的推理轨迹
- 企业级扩展性：专为私域及企业级部署而设计
社区贡献与数据集
我们提供公平匿名数据集 AnonyRAG ，有效防范大语言模型预训练过程中的知识泄露问题，深度检验 GraphRAG 框架的检索性能。
我们致力于构建一个开放、灵活的知识图谱检索与推理框架。无论你是研究者、工程师，还是对知识图谱与 RAG 有兴趣的开发者，都可以在以下方向贡献：
新种子 Schema 开发：
设计并提交高质量的种子 Schema，帮助 GraphRAG 更好地理解不同数据类型。
示例：为医疗领域构建患者、药物、治疗方案的种子 Schema
自定义数据集集成:
在尽量减少对 Schema 的人工干预下，尝试集成新的开放数据集或行业数据集。
示例：
- 集成 WikiData、PubMed、arXiv 等开放数据集
- 集成企业内部文档或日志数据，并验证 Graphrag 的兼容性
特定领域的最佳实践应用案例
展示 GraphRAG 在某一领域的最佳实践，让社区更直观地了解其应用潜力。
示例：
- 金融领域：构建基于 Graphrag 的风险事件知识图谱
- 教育领域：集成课程大纲、作业与考试题库，辅助智能问答
- 科研领域：集成论文数据集，支持跨学科知识发现
..
#xxx
..