从昨天开始Hacker News 上有一个帖子持续出现在我时间线上“Ask HN: Dear Anthropic, can we please have thought traces back?”帖子标题很客气但底下回复一点都不客气。大量开发者表示他们在做 Agent、做评估、做调试时非常依赖模型在推理过程中暴露出来的思考痕迹。现在看不到了整个工作流等于少了一只眼睛。这不是普通用户对“AI 能不能解释自己”的哲学好奇。它牵涉到一个非常实际的问题当大模型成为你系统的一部分你要不要有能力知道它“为什么”给出这个结果我的判断是思维轨迹thought traces不是锦上添花的功能而是 AI 应用开发中调试、评估、审计的基础设施。Anthropic 在安全与透明度之间选择了更保守的路线这个取舍短时间内不会有标准答案但开发者必须理解它并掌握替代方案。这篇文章我会从思维轨迹这个概念的来龙去脉讲起分析为什么开发者如此依赖它当前 API 能力边界在哪里以及在没有完整思维链的情况下我们能用什么工程手段保住“可解释性”。1. 这篇文章真正要解决的问题先明确几个前提。这里的 thought traces指的是模型在推理过程中内部生成的中间步骤也就是我们常说的思维链Chain-of-Thought, CoT在接口层面的可见性。很多读者可能觉得大模型不就是一个黑盒吗输入 prompt输出 result中间过程看不到是正常的。但问题没有这么简单。在过去一两年里各大模型厂商在“扩展思考”Extended Thinking功能上做了大量布局。Claude 3.7 Sonnet 时代Anthropic 在 API 里提供过思考预算参数模型会在用户不可见的内部空间做更长时间推理。OpenAI 的 o1、o3 系列更是把“推理模型”作为一个独立产品线来推。这些模型在回答复杂问题之前会先生成一条隐藏的推理链再做最终输出。于是开发者遇到一个矛盾推理模型是黑盒的但它的推理过程恰恰是判断输出质量的关键。如果模型在第一步理解错了用户意图后续所有步骤都会偏。你能看到最终结果错了但看不到是在哪一步错的。这种情况在传统软件开发里几乎是不可接受的。你写一个函数函数返回值不对你第一反应是打日志、加断点、看堆栈。到了 AI 应用这里你连断点都没地方打。所以 Hacker News 上那个帖子能火本质原因是开发者失去了调试 AI 应用的重要工具。这篇文章适合谁读使用 Claude API 开发 Agent 或自动化流程的工程师。正在做模型评估、需要对输出做归因分析的技术负责人。对 AI 可解释性有研究兴趣想知道当前技术边界和替代方案的读者。以及所有在“追求模型能力”和“理解模型行为”之间纠结的 AI 应用开发者。我会尽量抛开立场把这件事讲清楚为什么 thought traces 很重要为什么 Anthropic 要收紧以及我们还能怎么办。2. 思维轨迹Thought Traces到底指什么2.1 从思维链说起思维链这个概念最初来自 2022 年 Google 研究团队发表的论文Chain-of-Thought Prompting Elicits Reasoning in Large Language Models。核心发现是如果你在 Prompt 中给模型展示解题步骤模型就会学着在回答时把推理步骤写出来推理准确率明显提升。后来这发展成了两类东西提示词层面的思维链让模型在回答前显式输出“一步一步思考”这是用户能看见的。模型内部的思考机制模型在解码最终回答之前先生成大量内部推理 token这些 token 可能不返回给用户。后者在推理模型Reasoning Models中尤其明显。模型消耗的 token 分为“思考 token”和“输出 token”思考 token 占了很大一部分推理开销但用户可能完全看不到具体内容。2.2 Thought Traces 在这个语境下的含义Thought traces 在 Anthropic 的讨论语境中指的是那些模型在内部生成、但没有完整暴露给用户的思考过程。它有几个层级层级你能看到什么典型场景完整思维链模型每一步推理 token 全部可见早期 GPT-3 论文展示、提示工程调试摘要型思考模型输出一个“思考摘要”说明关键判断依据部分 API 工具展示的 reasoning summary预算 结果你知道模型思考了多久、用了多少 token但看不到内容当前 Anthropic 多数推理模型接口的默认策略完全不可见模型直接给出结论内部过程完全不透明部分闭源产品的默认模式开发者最喜欢的当然是第一种完整思维链。因为它最像传统软件里的 debug 日志。你一行行看模型怎么推理能精准定位到逻辑断裂点。但模型厂商并不是这么想的。从安全和商业角度看完整暴露思维链有非常多的顾虑。2.3 为什么模型厂商不愿意暴露完整思维链这里要提到一个在 AI 安全圈里被讨论很多的概念思维链窃取攻击Chain-of-Thought Stealing Attacks。如果你的模型在推理过程中暴露了详细思考过程攻击者可以通过精心构造的 Prompt诱导模型把内部推理链原样输出。一旦拿到这些推理链别人就能反向分析你的模型在关键判断上依赖了什么信号、使用了什么策略。这相当于把你的模型“风格”和“决策逻辑”暴露给了竞争对手。另一个风险是安全对齐。Anthropic 在设计模型时会在推理过程中注入大量安全策略判断比如检测到恶意请求后模型内部会有一套“拒绝”的推理。如果这些推理完全可见用户就能针对性地构造绕过安全机制的 Prompt。所以模型厂商的普遍做法是思考过程可以作为“计算资源”给到模型但不作为“信息内容”返回给用户。这个立场本身有合理性。但对开发者来说这确实造成了调试困难。这是今天争论的核心。3. 为什么这次讨论集中在 Anthropic 身上3.1 Hacker News 帖子的背景这次 Hacker News 帖子直接点名 Anthropic不是偶然。从公开信息看Anthropic 在 Claude 3.7 Sonnet 时代提供了扩展思考能力但社区反馈显示后来产品策略有所调整思维轨迹在接口层面对开发者变得不可用或不可见了。很多开发者的第一反应是我产品都做好了评估体系也是围绕思维链设计的突然不提供了整个链路就断了。这种“依赖断裂”是社区情绪激烈的直接原因。3.2 Anthropic 的透明与安全矛盾Anthropic 这家公司有个特点它是所有头部 AI 公司里最强调安全对齐的。从他们的公开技术博客和工作来看团队在“可解释性”上投入很大但“可解释性研究”和“向用户暴露思维过程”是两件不同的事情。Anthropic 的研究方向主要是机制可解释性Mechanistic Interpretability也就是通过分析模型的内部结构、神经元激活模式、特征提取从底层理解模型为什么这么想。这不是把推理 token 打印给你看。所以会出现一个看似矛盾的局面一家做可解释性研究做得最认真的 AI 公司在产品端却在收紧思维过程的可见性。原因就在于机制可解释性是给研究者和安全团队“内部审计”用的而 thought traces 一旦暴露给外部用户就进入了“外部攻击面”的范畴。两者在安全模型里是完全不同的。3.3 Anthropic 与 OpenAI 的 API 设计差异顺带说一下社区里经常有人问 Anthropic 和 OpenAI 的 API 是否兼容。从接口设计上两者差别很大维度Anthropic Claude APIOpenAI API消息结构使用系统提示 多轮消息使用 system messages工具调用工具与消息分离使用 tool_use 块使用 tool_calls推理模型参数thinking 配置块定义预算reasoning_effort 参数定义低/中/高思考过程可见性有思考预算但内容不可见部分模型提供 reasoning summary从实际经验看两者最大的差别不是单词拼写而是设计哲学。Anthropic 把思考过程当作模型内部的“执行资源”OpenAI 则在某些模型上做了更细粒度的 reasoning summary 输出。这也是开发者觉得 Anthropic 更“保守”的原因之一。4. 思维轨迹对开发者工作流的重要价值这一节要说清楚开发者要 thought traces不是好奇心是真的有实际需求。我从几个典型场景展开。4.1 场景一RAG 应用调试RAG检索增强生成应用是目前最常见的 AI 落地形态。用户问一个问题系统先从知识库检索候选文档再交给模型生成答案。这里最容易出错的地方是检索到的内容明明是正确的但模型没有用。它可能被 Prompt 里其他信息带偏了也可能自己脑补了一段“看起来合理但其实是错的”内容。如果你能看到模型的思维轨迹你可以很清楚地判断模型到底有没有意识到自己应该基于检索结果回答它在生成最终答案时主要参考了哪段内容看不到思维轨迹你只能一遍一遍改 Prompt、改检索策略然后看输出有没有变好。这个过程的效率非常低。4.2 场景二Agent 工具调用失败归因在 Agent 场景下模型需要决定“什么时候调用工具”“调用哪个工具”“参数怎么传”。这里面每一步都是决策点。一个典型失败案例是模型在第一步分析用户意图时判断错了导致它调用了一个完全无关的工具最终返回结果当然也不对。没有思维轨迹你只能看到模型调用了某个工具传了某些参数最后失败了。但你看不到它在调用工具之前是怎么权衡的——它为什么没有选择另一个候选工具它是否误解了用户问题中的某个关键词有经验的开发者可以通过分析工具调用日志来反推但这比直接看思维链慢太多。4.3 场景三模型评估与回归测试做 AI 应用评估是绕不开的。你需要准备一组评估集每次改 Prompt 或升级模型后跑一遍看效果有没有变差。评估最大的难点是“分析失败原因”。一条测试用例从通过变成不通过原因可能有很多模型泛化能力下降、Prompt 语义变了、检索结果变了、模型内部随机性变了。思维轨迹在这里的作用是“归因依据”。你能看到模型在这一版里是怎么推理的上一版是怎么推理的两者在哪一步分岔了。没有这个信息评估就变成了只看分数的黑盒测试。分数降了原因不明分数涨了也说不清为什么涨的。4.4 场景四合规审计与风险控制如果 AI 系统是用在金融、医疗、法务等领域你很可能需要记录每次决策的依据。监管方会问这个系统为什么给这个客户批了贷款为什么给这个病人推荐这个药思维轨迹在合规视角下有点像“AI 的决策日志”。虽然它不能完全解释模型行为因为模型真正决策过程在神经网络权重里但它至少给出了一条可追踪的推理线索。如果连这条线索都没有合规审计将变得非常困难。5. 当前 Anthropic API 的能力边界与对照实践5.1 Claude API 中的思考模式现在 Claude API 提供了思考模式通过thinking参数启用。启用后模型会在生成最终回答前“思考”一段时间消耗独立的思考预算。下面是一个最小调用示例from anthropic import Anthropic client Anthropic() response client.messages.create( modelclaude-3-7-sonnet-20250219, max_tokens8192, thinking{ type: enabled, budget_tokens: 4096 }, messages[ { role: user, content: 给定一个整数数组找到两个数使它们的和等于目标值。返回这两个数的下标。数组为 [2, 7, 11, 15]目标值为 9。 } ] ) # 打印最终响应内容 for block in response.content: print(block.type, block.text if block.type text else block)需要说明的是启用思考模式后temperature参数在 Anthropic API 中必须设为 1或保持默认因为模型进入思考模式后对温度控制有独立逻辑。这里容易踩坑的地方是budget_tokens是思考部分的最大 token 预算max_tokens是最终回答的最大 token 数。两者是独立的不要把max_tokens设置得小于思考预算否则可能造成请求被截断。如果你收到类似这样的报错BadRequestError: thinking is not supported with temperature other than 1第一反应就是检查代码里是否显式设置了temperature把它移除或改成 1。5.2 没有完整思维链时怎么保证可解释性面对当前接口的约束最现实的做法是不依赖模型内部思维链而是从工程层面建立可观测性。一个非常有效的方式是在 Prompt 中要求模型输出结构化的“决策摘要”。这不是让模型“假装思考”而是要求模型在最终回答中包含它认为最关键的决定因素。system_prompt 你是一个代码审查助手。在完成分析后你必须按以下 JSON 结构输出 { conclusion: 最终的审查结论或修复建议, evidence: [支撑结论的关键代码证据1, 证据2, 证据3], risks: [识别到的风险点1, 风险点2], assumptions: [你在分析中做的合理假设尤其是信息不足时] } 要求 - evidence 必须来自用户提供的代码不要编造。 - risks 要具体到代码位置或逻辑不要只说“存在性能问题”。 - assumptions 很重要如果你因为缺少上下文做了猜测必须写出来。 这样我们才能审计你的判断依据。 response client.messages.create( modelclaude-3-7-sonnet-20250219, max_tokens2048, messages[ {role: system, content: system_prompt}, {role: user, content: 请分析这段代码的复杂度并给出优化建议\n\nfor i in range(n):\n for j in range(i):\n total j} ] ) print(response.content[0].text)这样做有三个好处。第一你拿到了一份可解析的“决策摘要”方便后续自动评估和审计。第二模型在生成assumptions字段时实际上是在输出它推理过程中最不确定的部分这比完整思维链更精炼也更安全。第三这种结构化的输出可以被记录到日志系统里成为长期可观测数据。虽然它不能完全替代思维链但在当前接口约束下这是性价比最高的替代方案。5.3 用中间状态日志构建“伪推理链”另一个常用思路是把你的业务流程拆成多个步骤在每一步之间显式获取模型的中间输出并记录到日志中。import json import time def run_agent_pipeline(user_question): log {} start time.time() # 第一步意图理解 intent_response client.messages.create( modelclaude-3-7-sonnet-20250219, max_tokens512, messages[ {role: user, content: f判断用户意图只返回一个词查询、修改、计算 或 不清楚。用户问题{user_question}} ] ) intent intent_response.content[0].text.strip() log[intent] intent log[intent_latency_ms] int((time.time() - start) * 1000) # 第二步根据意图决定下一步动作 if intent 查询: log[next_action] plan_query elif intent 计算: log[next_action] call_calculator else: log[next_action] ask_clarification # 第三步记录决策摘要 log[decision_reason] f根据用户问题识别到意图为{intent}因此选择动作{log[next_action]} # 把日志写入文件 with open(./agent_log.jsonl, a, encodingutf-8) as f: f.write(json.dumps(log, ensure_asciiFalse) \n) return intent, log[next_action]这种方式的核心思想是既然模型内部的思维链不可见那就把每一步决策都变成一次独立的 API 调用并把结果落盘。这样你的系统就有了自己的“决策日志”虽然不是模型的完整思维链但关键决策点全部有迹可循。缺点也很明显多步 API 调用会带来更高的延迟和成本。所以一般是只对关键路径做这种拆解不是每个用户请求都走全流程。5.4 记录请求元数据进行事后审计最后一个非常容易被忽略但极其重要的实践记录所有请求的元数据。import logging logger logging.getLogger(__name__) def log_model_call(params, response): usage getattr(response, usage, None) logger.info( model_call, extra{ model: params.get(model), max_tokens: params.get(max_tokens), thinking_enabled: params.get(thinking, {}).get(type) enabled, thinking_budget: params.get(thinking, {}).get(budget_tokens), input_tokens: usage.input_tokens if usage else None, output_tokens: usage.output_tokens if usage else None, stop_reason: getattr(response, stop_reason, None), } )这段代码的作用是不管你调用了什么模型、启没启用思考模式、消耗了多少 token都要把元数据记下来。从实际项目经验看很多 AI 应用上线后出现问题第一难点不是没有日志而是日志不完整——你不知道当时传了什么参数、用了什么模型版本、思考预算设置了多少。等到排查问题时发现关键信息全丢了。所以请务必把下面这些信息记全模型名称和版本最大 token 数和思考预算输入 token 和输出 token 数量停止原因长度截断还是正常结束Prompt 摘要或完整 Prompt最终输出摘要或完整输出6. 可解释性的技术探索Anthropic 到底在研究什么6.1 从机制可解释性到思维轨迹的差距如果只看产品端的限制你可能觉得 Anthropic 对透明度这件事不上心。但事情恰恰相反。Anthropic 在机制可解释性方向做过很多公开研究。他们的思路是不去看模型“说了什么”而是看模型的“内部状态”——通过分析神经元激活模式、特征分布理解模型在概念层面是怎么组织知识的。打个比方思维轨迹是模型在最终回答前写下的“演算草稿”而机制可解释性是直接观察模型大脑的“神经活动”。前者是过程记录后者是底层机制。从安全角度看机制可解释性研究的价值在于如果能准确识别模型的内部特征比如“它是否在欺骗”“它是否误解了用户意图”就能在模型生成危害内容之前拦截而不是等到输出结果出现后再发现。但这套研究离产品化还有距离。普通开发者拿不到这些内部特征分析结果只能看到最终生成的文本。所以机制可解释性研究真正受益的对象目前还是模型厂商自己而不是外部开发者。6.2 为什么“提取特征”不等于“推理过程可见”Anthropic 发布过一些关于“提取数百万特征”的研究成果。他们用稀疏自编码器Sparse Autoencoders等工具从模型中提取可解释的特征并把这些特征映射成人类能理解的概念。但这里有一个容易混淆的点提取出特征不代表你能看到模型每一步的推理逻辑。特征提取告诉你的是“模型在某个内部层激活了哪些概念”而不是“模型因为这些概念所以决定调用这个工具”。两者之间的因果关系仍然非常复杂。所以即使可解释性研究大幅推进也不意味着 API 会向所有用户开放“完整思维链”。更可能的是模型厂商利用这些研究做内部安全监控或在特定合规场景下提供有限的解释报告。对于普通开发者来说现阶段不要对“完整思维链可见”抱太高期望。更务实的路线是在产品层面建立完善的输入输出日志体系。在 Prompt 层面要求模型输出结构化决策摘要。在流程层面把关键决策点拆成可观测的独立步骤。7. 常见问题与排查思路问题现象可能原因排查方式解决方案调用 API 报错thinking is not supported with temperature other than 1启用了 thinking 后仍显式设置 temperature检查调用代码和配置文件移除 temperature 参数或设为 1返回结果在思考部分被截断max_tokens设置过小不够最终回答输出查看返回的stop_reason是否为max_tokens增大max_tokens确保大于思考预算和预期输出长度看不到任何思考内容当前接口策略就是不返回完整思维链检查返回 content 中 block 类型使用结构化决策摘要方式替代请求延迟明显变高启用了思考模式且思考预算较大查看日志中延迟统计降低budget_tokens或在非必要场景关闭 thinking网络层面报failed to connect to api.anthropic.com网络环境无法正常访问该 API 域名检查网络连通性和 DNS确保网络环境可以正常访问目标 API排查本地代理配置成本明显上升每个请求都走全流程多步调用检查日志中每步 token 消耗对简单请求走轻量模型/少步骤流程复杂请求再开启完整思考表格里第一个问题需要再强调一次Anthropic 在启用 thinking 模式后对 temperature 的限制是严格的。很多从 OpenAI 迁移过来的开发者习惯传一个 temperature0.7结果直接报错。第二个问题也很隐蔽。budget_tokens代表着模型在内部思考期间最多能用的 token 数max_tokens是最终回答的最大 token 数。如果你把max_tokens设成和budget_tokens一样大那么在长回答场景下最终回答可能没有足够的 token 空间输出完导致截断。8. 最佳实践与工程建议8.1 不要把你的核心逻辑绑死在“可见思维链”上这是最重要的一条经验。如果你正在开发 AI 应用请务必不要把“能读取模型内部思维链”作为系统的核心依赖。因为模型厂商调整策略的成本很低而你的应用一旦建立在这个能力上就会非常脆弱。正确的做法是假设思维链不可见从一开始就设计自己的可观测体系。包括结构化输出、决策摘要、中间步骤日志、请求元数据记录。这些是你自己能控制的不会因为厂商改策略就失效。8.2 合理设计思考预算思考预算不是越大越好。从成本角度思考 token 是要花钱的。从延迟角度思考时间越长用户体验越差。从效果角度很多简单问题根本不需要深度思考强行开启大预算反而可能在低价值场景上浪费时间。建议按业务场景分层业务场景是否开启思考建议预算简单分类、关键词提取关闭无常规问答、代码补全关闭无复杂代码审查、多步推理开启中低预算高风险决策合规、法务开启中高预算并配合日志审计8.3 建立评估回归集无论你是否能看到思维链评估集都是必须的。建议维护一个 50-200 条的评估集覆盖正常场景、边界场景和失败场景。每次修改 Prompt、升级模型、调整思考预算后都跑一遍评估集对比前后效果。如果得分下降结合你的结构化决策摘要和日志去定位问题而不是凭感觉调 Prompt。8.4 安全与合规提醒如果你在金融、医疗、法律等高风险领域使用推理模型要注意思维轨迹不可见不代表你可以免除审计责任。你需要通过自己的日志体系保证决策依据可追溯。即使未来某个模型开放了思维链也不要直接把完整思维链写入数据库。思维链可能包含敏感信息、用户隐私数据甚至安全管理策略。写入前必须做脱敏处理。对用户输入也做脱敏。不要把用户身份证号、手机号、健康信息直接传给大模型除非你有完善的隐私保护机制。8.5 日志记录的最低标准最后给出一份最低限度的日志字段清单请求 ID时间戳模型名称与版本系统 Prompt 摘要用户输入摘要完整输出输入 token 数输出 token 数思考预算配置停止原因延迟是否重试有了这些字段即使拿不到模型内部思维链你也能在问题发生后做基本的过程回溯。9. 总结与后续学习方向Thought traces 在 Hacker News 上成为热门话题不是因为开发者群体矫情而是因为它切中了 AI 工程化过程中最痛的一环可观测性。一套成熟的 AI 应用不应该只关心模型输出的准确率还应该关心我们能不能理解、调试、审计模型的行为。思维轨迹之争表面上是“要不要把模型的思考过程给我看”本质上是“AI 系统的运维和审计标准应该是什么”。从当前的信息来看Anthropic 在安全和透明度之间选择了偏保守的路线短期内不太可能把完整思维链大规模开放给所有 API 用户。开发者与其等待厂商改变策略不如尽早建立属于自己的可观测体系使用结构化决策摘要替代思维链保证关键判断有迹可循。把业务流程拆成可独立观测的步骤每步落日志。完整记录请求元数据包括 token 消耗、模型版本、停止原因。在所有关键任务中接受“思维链不可见”这个前提把工程兜底做好。如果你对这条线索感兴趣接下来可以深入研究几个方向Anthropic 的机制可解释性研究理解模型内部特征是如何被提取和解释的。推理模型Reasoning Models在不同任务上的最佳实践搞清什么时候该开思考模式什么时候该关。大模型应用的评估方法论学习如何构建高质量评估集用系统化的方式提升 AI 应用的可靠性。多智能体系统的日志与追踪设计在多个模型协作场景下建立端到端的可观测性。最后实用建议如果你正在用 Claude API 搭 Agent 或 RAG 应用这周就可以做一件事——检查你的请求日志里有没有记录 model、budget_tokens、stop_reason 这三个字段。没有的话补上。它不会让你的模型输出立刻变好但下次出问题时你至少知道从哪里开始查。
尧图网络