你在使用 AI 提高生产力。那为什么你比以前更疲惫？每个工程师都需要面对的悖论。

上季度我产出的代码比职业生涯任何时候都多。但我也比职业生涯任何时候都更疲惫。这两件事并非无关。

我的工作就是构建 AI 代理基础设施。我是 OpenFGA（云原生计算基金会孵化项目）的核心维护者之一，我构建了 agentic-authz 用于代理授权，我构建了 Distill 用于上下文去重，我交付了 MCP 服务器。我不是那种业余玩 AI 的人。我身处其中。我构建的是其他工程师用来在生产环境中运行 AI 代理的工具。

然而，我撞上了一堵墙。那种无论多少工具或工作流优化都无法解决的疲惫。

如果你是一名每天使用 AI 的工程师——用于设计评审、代码生成、调试、文档、架构决策——而且你注意到自己比以前更累了，这不是你的错觉。你没有问题。你正在经历一些真实存在的事情，而这个行业却在 aggressively 假装它不存在。如果一个全职构建代理基础设施的人都会在 AI 上倦怠，那它可能发生在任何人身上。

我想诚实地谈谈。不是"AI 太棒了，这是我的工作流"版本。是真实版本。那个在晚上 11 点盯着屏幕、被 AI 生成的代码包围、仍然需要审阅的人，想着为什么那个本该节省你时间的工具却消耗了你一整天。

没有人警告我们的悖论
一旦你看清这一点，原因就很简单，但我花了几个月才明白。AI 确实让单个任务变快了。这不是谎言。以前需要 3 小时的事情现在只需 45 分钟。起草设计文档、搭建新服务、编写测试用例、研究不熟悉的 API。都快了。

但我的日子变得更难了。不是更简单。是更难。

原因很简单：每个任务花的时间更少了，但你不会做更少的任务。你会做更多的任务。你的能力看起来扩展了，所以工作也随之扩展。还会更多。你的经理看到你交付更快了，所以期望也调整了。你看到自己交付更快了，所以自己的期望也调整了。基准线移动了。

在 AI 之前，我可能会花一整天在 一个设计问题上。我会在纸上草图，在淋浴时思考，散步走走，回来时思路清晰。节奏慢但认知负荷可控。一个问题。一天。深度专注。

现在呢？我一天可能会处理六个不同的问题。每个"用 AI 只花一小时"。但在大脑之间切换六个问题是极其昂贵的。AI 在问题之间不会累。我会。

这就是悖论：AI 降低了生产成本，却增加了协调、审查和决策的成本。而这些成本完全落在了人类身上。

你成为了审阅者，却没有人告诉你
在 AI 之前，我的工作是：思考问题，写代码，测试它，交付它。我是创造者。制造者。这就是吸引我们大多数人来工程领域的原因——构建的行为。

在 AI 之后，我的工作越来越多变成了：提示，等待，读取输出，评估输出，判断输出是否正确，判断输出是否安全，判断输出是否符合架构，修复不匹配的部分，重新提示，重复。我变成了审阅者。裁判。质量检查员，在一条永不停歇的生产线上。

这是一种根本不同的工作。创造是充满能量的。审阅是消耗精力的。有研究支持这个——生成性任务和评估性任务之间的心理差异。生成性工作给你心流状态。评估性工作给你决策疲劳。

我最先注意到的是在我一周内大量使用 AI 开发一个新微服务的时候。到了周三，我无法再做简单的决定了。这个函数应该叫什么？我不在乎。这个配置应该放在哪里？我不在乎。我的大脑满了。不是因为写代码——而是因为评审代码。一整天，数以百计的小判断。

残酷的讽刺是，AI 生成的代码比人类编写的代码需要更仔细的审阅。当一个同事写代码时，我知道他们的模式、他们的长处、他们的盲点。我可以略过我信任的部分，专注于我不信任的部分。对于 AI，每一行都可疑。代码看起来很自信。它能编译。它甚至可能通过测试。但它可能在生产环境中 subtly 错误，在负载下，在凌晨 3 点才暴露。

所以你阅读每一行。而阅读你没有写的代码，是被一个不理解你的代码库历史或你的团队约定的系统生成的，是令人精疲力竭的工作。

这也就是为什么我认为代理安全和授权如此重要。如果我们不能审查 AI 产生的一切——我们不能规模化地做到——那么我们需要系统来首先约束代理能做什么。最少权限访问、作用域令牌、审计跟踪。"AI 做了什么危险的事情吗"这个问题越不需要担心，你在真正重要的工作上就有更多认知预算。这不只是安全问题。这是人类可持续性问题。

非确定性问题
工程师接受确定性训练。同样的输入，同样的输出。这就是契约。这就是让调试成为可能的原因。这就是让推理系统成为可能的原因。

AI 打破了这个契约。

我有一个提示在周一完美工作。为 API 端点生成干净、结构良好的代码。周二我用同样的提示做类似的端点。输出结构不同，使用了不同的错误处理模式，引入了我没有要求的依赖。

为什么？没有理由。或者更准确地说，没有我能访问的理由。"模型今天决定走不同方向"没有堆栈跟踪。"温度采样选择了路径 B 而不是路径 A"没有日志。它就是……不同地发生了。

对于一个整个职业生涯都建立在"如果它坏了，我能找出原因"的人来说，这令人深感不安。不是戏剧性的方式。是缓慢的、grinding的、背景焦虑的方式。你永远无法完全信任输出。你永远无法完全放松。每次互动都需要警惕。

我试图对抗这个。我版本控制我的提示。我构建了详尽的系统消息。我创建了模板。有些帮助。没有什么能解决根本问题：你正在与一个概率系统协作，而你的大脑是为确定性系统设计的。那种不匹配是一种持续的、低度的压力来源。

这种沮丧实际上促使我构建了 Distill——用于 LLM 的确定性上下文去重。没有 LLM 调用，没有嵌入，没有概率启发式。纯算法在 ~12ms 内清理你的上下文。我希望 AI 管道中至少有一部分是我可以推理、调试和信任的。如果模型的输出是概率性的，我能做的最少是确保输入是干净和可预测的。

我见过的处理这个问题的最好的工程师是那些已经接受了它的人。他们把 AI 输出当作一个聪明但不可靠的实习生的初稿。他们期望重写 30% 的内容。他们为此预算时间。当输出错误时他们不会沮丧，因为他们从不期望它是对的。他们期望它是有用的。这是有区别的。

FOMO 跑步机
深呼吸，试着跟上最近的几个月。Claude Code 交付了子代理，然后是技能，然后是 Agent SDK，然后是 Claude Cowork。OpenAI 推出了 Codex CLI，然后是 GPT-5.3-Codex——一个 literally 帮助编写自己的代码的模型。新的编码代理宣布后台模式有数百个并发自主会话。Google 推出了 Gemini CLI。GitHub 添加了 MCP Registry。每周都有收购。Amazon Q Developer 获得代理升级。CrewAI、AutoGen、LangGraph、MetaGPT——选择你的代理框架，每周都有一个新的。Google 宣布 A2A（代理到代理协议）来与 Anthropic 的 MCP 竞争。OpenAI 交付了自己的 Swarm 框架。Kimi K2.5 推出了代理 swarm 架构编排 100 个并行代理。"氛围编码"成为一种事物。OpenClaw 推出了技能市场，一周内，研究人员在 ClawHub 上发现 400+ 恶意代理技能上传。而在这一切的中间，某个在 LinkedIn 上发帖的人说"如果你不在 2026 年使用带子代理编排的 AI 代理，你已经过时了。"

这不是一年。是几个月。而且我在遗漏东西。

我严重陷入了这个陷阱。我周末花时间评估新工具。阅读每一个变更日志。观看每一个演示。试图保持在前沿，因为我害怕落后。

这实际上看起来像什么：我会花周六下午设置一个新的 AI 编码工具。到周日我会有一个基本工作流。到下周三，有人会发布一个"好得多"的不同工具。我会感到一阵焦虑。到下一个周末，我会在设置新东西。旧的东西会闲置不用。一个编码助手到下一个再下一个又回到第一个。每个迁移都花我一个周末，可能只有 5% 的改进，我甚至无法正确衡量。

乘以每一个类别——编码助手、聊天界面、代理框架、多代理编排平台、MCP 服务器、上下文管理工具、提示库、swarm 架构、技能市场——你会得到一个永远在学习新工具却从未深入任何一个的人。仅仅 Hacker News 首页就足以让你头晕目眩。一天是"Show HN: 自主研究 Swarm"，另一天是"Ask HN: AI swarm 如何协调？"没人知道。每个人都在构建。

最糟糕的是知识衰减。我在 2025 年初花了两个星期构建一个复杂的提示工程工作流。精心设计的系统提示、少样本示例、思维链模板。它效果很好。三个月后，模型更新了，提示最佳实践改变了，我的一半模板产生的效果比简单的单行提示还差。那两个星期没了。不是投资。是花了。我的 MCP 服务器设置也发生了同样的事情——我构建了五个自定义服务器（Dev.to 发布器、Apple Notes 集成、Python 和 TypeScript 沙箱，还有更多），然后协议进化了，然后 MCP Registry 在 GitHub 上推出了，突然有数千个预构建的可用。一夜之间我的一些自定义工作变得多余了。

代理框架流失更糟糕。我看到团队在一年内从 LangChain 到 CrewAI 到 AutoGen 到自定义编排。每次迁移都意味着重写集成、重学 API、重建工作流。那些等待和什么都不做的人通常比那些早期采用并不得不迁移两次的人处于更好的位置。

我从此采用了不同的方法。不是追逐每一个新工具，而是在它们下面的基础设施层深入。工具来了又走。它们解决的问题不会。上下文效率、代理授权、审计跟踪、运行时安全——这些是持久的问题，无论本月哪个框架流行。这就是为什么我在 OpenFGA 上构建 agentic-authz 而不是将其绑定到任何特定的代理框架。这就是为什么 Distill 在上下文级别工作，而不是在提示级别工作。在不会流失的层面上构建。

我仍然密切跟踪这个领域——你在为它构建基础设施时必须这样做。但我跟踪是为了理解生态系统的走向，而不是采用每一个新东西。知情和反应式是有区别的。

"再一个提示"陷阱
这个很阴险。你试图让 AI 生成某些特定的东西。第一个输出 70% 正确。所以你优化你的提示。第二个输出 75% 但打破了第一个正确的东西。第三次尝试：80% 正确但现在结构不同了。第四次尝试：你已经花了 45 分钟，你本来可以在 20 分钟内从头写出这个东西。

我称之为提示螺旋。这是 AI 版的剃须。你从一个明确的目标开始。30 分钟后你在调试你的提示而不是调试你的代码。你在优化给语言模型的指令而不是解决实际问题。

提示螺旋特别危险，因为它感觉像是在生产。你在迭代。你在接近。每次尝试都稍微好一点。但边际收益正在迅速递减，而你忘记了目标从来不是"让 AI 产生完美的输出"。目标是交付功能。

我现在有一个硬性规则：三次尝试。如果 AI 在三次提示中没有让我达到 70% 可用，我就自己写。没有例外。这条规则节省了我的时间比任何我学过的提示技术都多。

完美主义遇见概率输出
工程师倾向于完美主义。我们喜欢干净的代码。我们喜欢通过的测试。我们喜欢可预测的系统。这是一个特性，不是 bug——这就是让我们擅长构建可靠软件的原因。

AI 输出从不完美。它总是"挺好"。70-80% 在那。变量名有点 off。错误处理不完整。边缘情况被忽略了。对于你的代码库来说抽象是错误的。它能工作，但不对。

对于完美主义者来说，这是折磨。因为"几乎正确"比"完全错误"更糟糕。完全错误，你扔掉重新开始。几乎正确，你花一个小时修补。而修补 AI 输出特别令人沮丧，因为你正在修复别人的设计决策——那些由一个不共享你的品味、你的上下文、你的标准的系统做出的决策。

我学会了放手。不是放弃质量——我仍然关心质量。而是放弃 AI 会产生质量的期望。我现在把每一个 AI 输出当作粗糙的草稿。起点。原材料。我一看到它就在心里标记为"草稿"，而这种 framing 的改变alone 将我的沮丧减少了一半。

在 AI 中最挣扎的工程师往往是最好的工程师。那些标准最高的工程师。那些注意到每一个不完美的人。AI 奖励一种不同的技能：从不完美的输出中快速提取价值的能力，不要执着于让它变得完美。

思维萎缩
这个最让我害怕。

我是在一次设计评审会议上注意到的。有人让我在白板上推理一个并发问题。没有电脑。没有 AI。只有我和一支笔。我挣扎了。不是因为我不了解这些概念——我了解。但我好几个月没有锻炼那块肌肉了。我一直在把初稿思维外包给 AI，以至于我的从头思考能力已经退化了。

这就像 GPS 和导航。在 GPS 之前，你构建心理地图。你了解你的城市。你可以推理路线。多年 GPS 之后，没有它你无法导航。技能萎缩了，因为你停止使用它了。

同样的事情正在 AI 和工程思维中发生。当你总是先问 AI，你就停止构建来自自己挣扎问题的神经通路。挣扎是学习发生的地方。困惑是理解形成的地方。跳过那个，你得到更快的输出但更浅的理解。

我现在故意在没有 AI 的情况下度过一天中的第一个小时。我在纸上思考。我手工画架构。我用慢速方式推理问题。它感觉低效。它确实是低效的。但它保持我的思维敏锐，而这种敏锐在我确实使用 AI 的那天剩余时间会带来红利——因为当我自己推理能力热身时，我可以更好地评估它的输出。

比较陷阱
社交媒体上充满了似乎已经掌握 AI 的人。他们发布他们的工作流。他们的生产力数字。他们的"我用 AI 在 2 小时内构建了整个应用"帖子。然后你看看你自己的体验——失败的提示、浪费的时间、不得不重写的代码——你想：我怎么了？

你没有问题。那些帖子是精选片段。没有人发布"我花了 3 小时试图让 Claude 理解我的数据库模式，最终放弃了，手动写了迁移。"没有人发布"AI 生成的代码导致了生产事件，因为它悄悄吞掉了一个错误。"没有人发布"我累了。"

比较陷阱被放大的原因是 AI 技能很难衡量。传统工程，你可以看一个人的代码并大致估计他们的能力。使用 AI，输出取决于模型、提示、上下文、温度、月相某人令人印象深刻的演示可能无法在你的机器上用你的代码库重现。

我对社交媒体上的 AI 内容变得更加挑剔。我仍然密切跟踪这个领域——我必须，这是我的工作。但我转移了从消费每个人的热点帖子到专注于实际上构建和交付的人，而不仅仅是演示。信号与焦虑的比例很重要。如果一个 feeds 让你感到落后而不是知情，那它对你没有服务。

什么真正有帮助
我会具体说明是什么改变了我与 AI 的关系，从对抗性到可持续的。

时间限制 AI 会话。我不再以无限制的方式使用 AI。我设置计时器。用 AI 做这个任务 30 分钟。当计时器响起时，我交付我有的或切换到自己写。这同时防止了提示螺旋和完美主义陷阱。

将 AI 时间与思考时间分开。上午用于思考。下午用于 AI 辅助执行。这不是 rigid 的——有时我打破这个规则。但有默认结构意味着我的大脑以正确比例获得锻炼和帮助。

从 AI 接受 70%。我不再试图获得完美的输出。70% 可用是标准。我会自己修复其余的。这种接受是单一最大的 AI 相关挫折在我的工作流中的减少器。

对炒作周期保持战略意义。我跟踪 AI 领域因为我为它构建基础设施。但我停止采用每周发布的新工具。我使用一个主要的编码助手并深入了解它。当新工具经过数月而非数天证明了自己时，我才评估它们。知情和反应式是不同的。

记录 AI 在哪里帮助、在哪里没有帮助。我保持了一个简单的日志两周：任务，使用 AI（是/否），花费时间，对结果满意度。数据揭示了。AI 在样板文件、文档和测试生成上节省了我大量时间。它在架构决策、复杂调试和任何需要深入了解我的代码库的事情上让我花费时间。现在我知道什么时候该用它，什么时候不该。

不审查 AI 产生的所有东西。这很难接受。但如果你使用 AI 生成大量代码，你不可能以同样的严谨性审查每一行。我将审查精力集中在最重要的部分——安全边界、数据处理、错误路径——并依靠自动化测试和静态分析来处理其余的。非关键代码中的一些粗糙是可以接受的。

可持续性问题
科技行业在 AI 之前就有倦怠问题。AI 正在使它变得更糟，不是因为 AI 不好，而是因为 AI 移除了曾经保护我们的自然速度限制。

在 AI 之前，一天能产出多少是有上限的。那个上限由打字速度、思考速度、查找东西所需的时间设定。它有时令人沮丧，但它也是一个调节器。你无法工作到自己累死，因为工作本身施加了限制。

AI 移除了调节器。现在唯一的限制是你的认知耐力。而大多数人在认知极限被超越之前都不知道自己的极限是什么。

我在 2025 年底倦怠了。不是戏剧性的——我没有辞职也没有崩溃。我只是不再关心了。代码评审变成了橡皮图章。设计决策变成了"AI 建议的任何东西"。我在走过场，产出比以往任何时候都多，感受却越来越少。我花了一个月才意识到发生了什么，又花了一个月才恢复。

恢复不是关于使用更少的 AI。而是关于以不同的方式使用它。有边界地。有意图地。带着理解，我不是机器，我不需要与机器保持 pace。构建正确的东西而不是追逐趋势地 deliberate 构建。

讽刺的是，倦怠期间是我一些最好的工作发生的时候。当我停止尝试使用每一个 AI 工具并开始思考什么真正 broken，我第一次清楚地看到了问题。上下文窗口充满垃圾——那变成了 Distill。代理拥有全有或全无的 API 密钥访问——那变成了 agentic-authz。无法审计代理实际做了什么——那正在成为 AgentTrace。疲劳迫使我停止消费并开始构建。不是更快地构建更多功能，而是 deliberate 构建正确的东西。

真正的技能
这就是我认为 AI 时代真正的技能是什么。它不是提示工程。不是知道使用哪个模型。不是拥有完美的工作流。

它是知道何时停止。

知道 AI 输出何时足够好。知道何时自己写。知道何时关闭笔记本电脑。知道边际改进不值得认知成本。知道你的大脑是有限资源，保护它不是懒惰——是工程。

我们优化我们的系统以实现可持续性。我们添加断路器。我们实现背压。我们设计优雅降级。我们应该对自己做同样的事情。

AI 是我用过的最强大的工具。它也是最消耗精力的。两件事都是真实的。在这个时代茁壮成长的工程师不会是那些使用 AI 最多的。而是那些使用 AI 最明智的。

如果你累了，不是因为你做错了。这是因为这确实很困难。工具是新的，模式仍在形成，行业正在假装更多的产出等于更多的价值。它不是。可持续的产出才是。

我仍然每天在这个领域构建。代理授权、上下文工程、审计跟踪、运行时安全——使 AI 代理真正在生产环境中工作的基础设施。我比以往任何时候都更致力于 AI。但我以我的方式、我的节奏、构建重要的事情而不是追逐流行事物地 commitment。

照顾好你的大脑。这是唯一一个你拥有的，没有 AI 可以替换它。

via https://siddhantkhare.com/writing/ai-fatigue-is-real

体育科技：AI正在改变NFL的比赛方式

当全球目光聚焦于超级碗赛场时，一个不那么引人注目却价值数十亿美元的项目正在悄然重塑美国职业橄榄球联盟。NFL推行的"数字运动员"（Digital Athlete）计划利用人工智能技术分析球员的伤病风险，通过海量数据建模预测哪些球员在何种情况下可能受伤。该项目声称已帮助联盟球队节省了数亿美元的医疗和运营成本，同时显著延长了球员的职业寿命。在一个伤病频发、球员流动率极高的职业联赛中，AI不仅是一项技术投资，更是一种战略资产。阅读原文

文学创作：AI入侵言情小说领域

言情小说行业素来是新技术的早期采用者，而这一次，人工智能正在以一种颇具争议的方式渗透其中。据《纽约时报》报道，越来越多的言情小说作者开始使用Claude等AI工具辅助创作，却未能向出版社或读者坦诚披露这一事实。与此同时，笔名的使用变得愈发普遍——这既是为了规避AI生成内容的偏见，也是为了在日益拥挤的市场中建立辨识度。支持者认为AI解放了创作者的生产力，而批评者则担忧这将导致同质化内容的泛滥，最终削弱整个出版生态的健康发展。阅读原文

行业镜像：Moltbook现象与AI狂热反思

本周互联网上最热闹的"AI社交网络"Moltbook引发了一场颇具价值的行业反思。MIT Technology Review的评论文章指出，Moltbook与其说是展示了AI技术的未来前景，不如说是一面镜子，忠实地映射出全社会对人工智能的集体痴迷。这款由Reddit风格社区演变而来的"机器人社交平台"，在短短几天内吸引了大量关注，但随即暴露出内容空洞、用户留存困难等问题。这一现象揭示了一个更深层的悖论：当AI成为投资和舆论的绝对焦点时，真正有价值的应用创新反而可能被淹没在泡沫之中。阅读原文

开发者困境：AI疲劳与思维萎缩

一位软件工程师在个人博客中分享的"AI疲劳"体验引发了广泛共鸣。他指出，开发者在追逐AI实验室最新工具的过程中，往往陷入一种"错失恐惧症"（FOMO）的跑步机式循环——不断切换工具、学习新框架、适应新范式。与此同时，过度依赖AI辅助编程正在导致一种隐蔽的"思维萎缩"：代码产出效率提升了，但工程师对底层原理的理解却在退化。这一现象提出了一个关键问题：在AI工具日益强大的今天，技术人员应当如何平衡生产力提升与核心能力的保持？阅读原文

供应链警报：AI芯片关键材料短缺

一则来自《华尔街日报》的报道揭示了AI产业链中一个不太起眼却至关重要的瓶颈：T-glass。这种用于先进芯片的超薄玻璃基板目前严重供应短缺，而全球超过90%的产能集中在一家日本公司——Nittobo手中。更令人担忧的是，Nittobo在短期内并无扩产计划，导致T-glass价格急剧上涨。这一局面再次提醒人们，尽管AI模型和应用层万众瞩目，但底层材料供应链的脆弱性可能成为制约整个行业发展的关键因素。阅读原文

安全动态：OpenClaw强化AI平台安全审核

在AI安全领域，OpenClaw（原Moltbot）宣布与VirusTotal达成合作，所有发布至ClawHub平台的AI技能（skills）都将接受VirusTotal的威胁情报扫描。这一举措回应了业界对AI助手可能被滥用于生成恶意代码、传播虚假信息等安全风险的担忧。随着越来越多的企业和开发者将AI能力集成到核心工作流中，确保AI输出的安全性正在成为行业共识。VirusTotal的介入标志着AI平台正在从"先上线再修复"向"安全前置"的运营模式转变。阅读原文

结语

纵观昨日AI领域的新闻，我们看到的是一幅复杂而多维的图景：AI正在职业体育、文学创作、软件开发等领域深刻改变行业运作方式；与此同时，供应链瓶颈、开发者心理健康、内容生态诚信等挑战也日益凸显。当资本和舆论的聚光灯持续打在AI身上时，保持清醒的批判性思维或许比追逐每一个热点更为重要。

Claude Code 博士生学术研究完全指南

目录

1. Claude Code 简介
2. 环境配置与基础操作
3. 文献阅读与整理
4. 研究写作辅助
5. 数据分析与可视化
6. 研究规划与思路拓展
7. 高效工作流整合

简介

Claude Code 是 Anthropic 推出的命令行交互工具，相比网页版 ChatGPT，它具有以下独特优势：

• 文件系统直接操作：可读取、编辑、创建本地文件
• 代码执行能力：运行 Python、R 等脚本进行数据分析
• 长上下文处理：支持上传整本著作或大量文献进行分析
• 工作流自动化：通过脚本实现重复性任务的自动化

对于人文社科博士生而言，这意味着你可以：

• 一次性分析数十篇 PDF 文献
• 自动生成文献综述的初稿框架
• 快速格式化参考文献
• 批量处理调研数据

环境配置

安装与登录

# 安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 首次运行并登录
claude

# 按照提示完成浏览器认证

基础命令

推荐的文件组织结构

dissertation/
├── literature/          # 文献文件夹
│   ├── pdf/            # 原始 PDF
│   └── notes/          # 阅读笔记
├── data/               # 研究数据
│   ├── raw/            # 原始数据
│   └── processed/      # 处理后数据
├── writing/            # 写作文件
│   ├── chapters/       # 论文章节
│   └── drafts/         # 草稿
└── scripts/            # 自动化脚本

文献阅读

场景 1：单篇论文深度分析

将 PDF 放入工作目录，然后：

claude "请阅读 literature/pdf/article.pdf，总结其核心论点、研究方法、数据来源和主要结论"

Claude 会返回结构化的分析：

## 文献分析：《文章标题》

**核心论点**：作者认为...
**研究方法**：质性访谈 / 文本分析 / 历史比较...
**数据来源**：XXX档案、XX位受访者...
**理论框架**：基于 XX 学者的 XX 理论...
**主要发现**：
1. ...
2. ...
**对你研究的启示**：可与你的 XXX 研究形成对话

场景 2：多篇文献对比分析

claude "对比分析 literature/pdf 文件夹中的以下三篇文献：
- smith_2020.pdf（关于教育不平等）
- jones_2021.pdf（关于社会流动）
- wang_2022.pdf（关于文化资本）

请重点分析：1）它们的理论对话关系；2）方法论差异；3）研究结论的异同"

场景 3：批量文献摘要生成

创建一个 Python 脚本批量处理：

# scripts/batch_summarize.py
import os
import sys

pdf_folder = "literature/pdf"
pdfs = [f for f in os.listdir(pdf_folder) if f.endswith('.pdf')]

print(f"发现 {len(pdfs)} 篇文献：")
for pdf in pdfs:
    print(f"  - {pdf}")

然后让 Claude 帮你完善这个脚本，实现自动摘要和索引生成。

场景 4：文献综述框架生成

claude "基于 literature/notes 文件夹中的所有阅读笔记，生成一个关于'数字时代的文化传承'主题的文献综述大纲。要求：
- 识别主要研究脉络
- 找出研究空白
- 提出3个可能的研究问题"

研究写作

场景 5：段落扩写与润色

将你的草稿段落保存为 markdown 文件：

# 创建草稿文件
echo "教育在促进社会流动方面发挥重要作用。然而，现有研究忽视了数字化转型的影响。" > writing/drafts/intro.md

# 让 Claude 扩写
claude "请扩写 writing/drafts/intro.md 中的内容，增加：
1. 社会流动理论的简要回顾
2. 数字化转型的具体表现
3. 两者关联的研究空白说明
要求学术写作风格，引用格式预留占位符 [Author, Year]"

场景 6：多语言翻译与润色

claude "将以下中文摘要翻译成符合国际期刊规范的学术英文：

[粘贴你的中文摘要]

要求：
- 使用学术英语惯用表达
- 保持原意的精确性
- 符合 APA 摘要格式"

场景 7：参考文献格式转换

从 Zotero 导出 BibTeX，然后：

claude "将 references.bib 转换为 GB/T 7714 格式，并生成按作者姓氏排序的参考文献列表"

场景 8：章节结构优化

claude "分析 writing/chapters/chapter3.md 的论证结构，指出：
1. 逻辑跳跃之处
2. 论据薄弱的段落
3. 建议增加过渡句的位置
4. 与前后章节的衔接建议"

数据分析

场景 9：访谈资料编码辅助

将转录文本放入 data/raw/interviews/，然后：

claude "分析 data/raw/interviews/participant_01.txt，识别与'数字技术使用'相关的所有片段，并建议初步的编码标签"

返回结果示例：

## 初步编码建议

**技术接入**（12处提及）
- "我每天用手机刷短视频..." [P01-L23]
- "孩子们教我怎么视频通话..." [P01-L45]

**代际差异**（8处提及）
- "我们那时候没有这些..." [P01-L67]

**建议的编码体系**：
1. 技术接入 → 设备拥有、使用频率、技能水平
2. 代际关系 → 数字反哺、沟通模式变化
3. 文化实践 → 传统传承的新形式

场景 10：问卷数据清理与描述统计

claude "编写 Python 脚本读取 data/raw/survey.csv，完成：
1. 缺失值分析
2. 异常值检测
3. 生成人口统计学变量的频数表
4. 计算核心变量的均值、标准差
5. 导出清理后的数据到 data/processed/"

Claude 会生成完整的脚本：

import pandas as pd
import numpy as np

# 读取数据
df = pd.read_csv('data/raw/survey.csv')

# 缺失值分析
print("缺失值统计：")
print(df.isnull().sum())

# 描述统计
print("\n描述统计：")
print(df.describe())

# 保存清理后数据
df_cleaned = df.dropna(subset=['核心变量'])
df_cleaned.to_csv('data/processed/survey_cleaned.csv', index=False)

场景 11：词频分析与词云生成

claude "对 data/raw/text_corpus/ 中的所有文本文件进行词频分析，生成：
1. 高频词列表（去除停用词）
2. 词云可视化
3. TF-IDF 关键词提取"

场景 12：主题建模辅助

claude "使用 Python 对访谈文本进行 LDA 主题建模，要求：
1. 自动确定最优主题数（2-10范围）
2. 为每个主题生成代表性文本片段
3. 可视化主题分布
4. 生成可解释的标题"

研究规划

场景 13：研究问题精炼

claude "基于以下初步想法，帮我精炼研究问题：

'我想研究社交媒体对农村文化传承的影响'

要求：
1. 提出 3 个不同侧重点的具体研究问题
2. 每个问题说明适合的方法论
3. 指出潜在的理论贡献
4. 评估数据获取的可行性"

场景 14：理论框架构建

claude "我的研究涉及技术接受、文化认同和社区参与三个概念。请：
1. 检索这三个概念的经典理论
2. 分析它们之间的潜在关联
3. 建议一个整合性的理论框架
4. 提出可操作化的变量"

场景 15：方法论设计讨论

claude "我正在设计一个关于'数字原住民文化实践'的研究，考虑采用混合方法。

请讨论：
1. 质性 vs 量化方法的优劣
2. 混合方法设计的具体方案
3. 抽样策略建议
4. 潜在的效度威胁及应对"

工作流整合

场景 16：自动化文献管理

创建每日文献处理脚本：

# scripts/daily_literature.sh
#!/bin/bash

TODAY=$(date +%Y-%m-%d)
DOWNLOADS="$HOME/Downloads"
TARGET="literature/pdf/$TODAY"

# 移动当天下载的 PDF
mkdir -p "$TARGET"
mv "$DOWNLOADS"/*.pdf "$TARGET/" 2>/dev/null

# 生成摘要
echo "正在处理文献..."
claude "批量总结 $TARGET 中的所有 PDF，生成 literature/notes/$TODAY-summary.md"

echo "完成！摘要已生成：literature/notes/$TODAY-summary.md"

场景 17：Obsidian 笔记整合

如果你的笔记在 Obsidian 中：

claude "读取 ~/Obsidian/Research/ 文件夹中最近 30 天内修改的所有 markdown 文件，
提取关于'方法论'的笔记，生成一份方法论文档总结"

场景 18：Git 版本管理集成

# 提交写作进度
claude "帮我编写提交信息：
- 修改了 chapter2 的理论框架部分
- 补充了文献综述的第三小节
- 调整了全文引用格式"

# Claude 会建议：
# git commit -m "完善第二章理论框架，补充数字鸿沟文献综述
#
# - 重构 Bourdieu 文化资本理论的应用分析
# - 新增 van Dijk 数字鸿沟三维模型综述
# - 统一全文引用格式为 APA 7th"

场景 19：写作进度追踪

创建进度统计脚本：

claude "编写脚本统计 writing/chapters/ 中各章节的字数，生成进度报告"

生成的脚本示例：

import os
import glob

def count_words(filepath):
    with open(filepath, 'r', encoding='utf-8') as f:
        content = f.read()
        # 移除 markdown 标记
        text = content.replace('#', '').replace('*', '').replace('`', '')
        return len(text.split())

chapters = glob.glob('writing/chapters/*.md')
total = 0

print("论文章节进度：")
print("-" * 40)
for ch in sorted(chapters):
    words = count_words(ch)
    total += words
    print(f"{os.path.basename(ch):20} {words:>6} 字")
print("-" * 40)
print(f"{'总计':20} {total:>6} 字")
print(f"目标：80000 字 | 完成度：{total/800:.1f}%")

实用技巧总结

提示词模板

文献分析：

请阅读 [文件路径]，重点分析：
1. 研究问题与核心论点
2. 理论框架与关键概念
3. 研究方法（样本、数据来源、分析方法）
4. 主要发现与贡献
5. 局限性与对你研究的启示

写作辅助：

请润色以下段落，要求：
- 保持学术语气
- 增强论证逻辑
- 修正语法错误
- 预留引用标记 [Author, Year]

数据分析：

请编写 Python/R 脚本完成：
1. 数据清洗（缺失值、异常值处理）
2. 描述性统计
3. [具体分析任务]
4. 可视化输出

常见问题解决

结语

Claude Code 不是替代你的思考，而是放大你的研究能力。最有效的工作方式是：

1. 明确分工：你负责创造性思考，Claude 负责执行和整理
2. 迭代优化：从粗略提示开始，根据结果逐步细化
3. 保持批判：始终验证 Claude 输出的准确性
4. 建立工作流：将重复任务脚本化，节省时间用于核心研究

开始你的 AI 辅助研究之旅吧！

本文翻译自 anthropic blog

我们的 Research 功能使用多个 Claude 代理来更有效地探索复杂的主题。我们分享了工程挑战以及我们从构建该系统中吸取的经验教训。

Claude 现在拥有研究功能，使其能够在 Web、Google Workspace 和任何集成中进行搜索以完成复杂的任务。

这个多智能体系统从原型到生产的旅程教会了我们关于系统架构、工具设计和提示工程的重要课程。多代理系统由多个代理（LLM 在循环中自主使用工具）组成。我们的 Research 功能涉及一个代理，该代理根据用户查询规划研究流程，然后使用工具创建同时搜索信息的并行代理。具有多个代理的系统在代理协调、评估和可靠性方面带来了新的挑战。

这篇文章分解了对我们有用的原则——我们希望您在构建自己的多智能体系统时会发现它们很有用。

多代理系统的优势
研究工作涉及开放式问题，很难提前预测所需的步骤。您不能硬编码用于探索复杂主题的固定路径，因为该过程本质上是动态的并且依赖于路径。当人们进行研究时，他们倾向于根据发现不断更新他们的方法，并遵循调查过程中出现的线索。

这种不可预测性使 AI 代理特别适合研究任务。研究需要随着调查的展开而灵活地调整或探索切线联系。该模型必须自主运行多个回合，并根据中间结果决定要追求的方向。线性的一次性管道无法处理这些任务。

搜索的本质是压缩：从庞大的语料库中提炼洞察。子代理通过与自己的上下文窗口并行作来促进压缩，在为首席研究代理压缩最重要的标记之前同时探索问题的不同方面。每个子代理还提供关注点分离（不同的工具、提示和探索轨迹），从而减少路径依赖性并实现彻底、独立的调查。

一旦智能达到阈值，多代理系统就成为扩展性能的重要方式。例如，尽管人类个体在过去 100,000 年中变得更加聪明，但由于我们的集体智慧和协调能力，人类社会在信息时代的能力呈指数级增长。即使是一般智能的代理在作为个体作时也会面临限制;代理组可以完成更多工作。

我们的内部评估表明，多智能体研究系统尤其擅长涉及同时追求多个独立方向的广度优先查询。我们发现，在我们的内部研究评估中，以 Claude Opus 4 为主要代理和 Claude Sonnet 4 子代理的多代理系统的性能比单代理 Claude Opus 4 高出 90.2%。例如，当被要求识别信息技术标准普尔 500 指数中公司的所有董事会成员时，多智能体系统通过将其分解为子智能体的任务来找到正确答案，而单智能体系统通过缓慢的顺序搜索无法找到答案。

多代理系统之所以有效，主要是因为它们有助于花费足够的代币来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（测试浏览代理查找难以找到的信息的能力）中 95% 的性能差异。我们发现，令牌使用本身可以解释 80% 的方差，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们的架构，该架构在具有单独上下文窗口的代理之间分配工作，以增加更多并行推理能力。最新的 Claude 模型在代币使用方面起到了很大的效率乘数的作用，因为升级到 Claude Sonnet 4 比在 Claude Sonnet 3.7 上将代币预算翻倍要提高性能。多代理架构可以有效地扩展超出单个代理限制的任务的令牌使用。

有一个缺点：在实践中，这些架构会快速烧毁代币。根据我们的数据，代理通常比聊天交互多使用约 4× 个令牌，而多代理系统使用的令牌比聊天多约 15× 个。为了经济可行性，多代理系统需要任务价值足够高的任务，以支付更高的性能。此外，一些要求所有代理共享相同上下文或涉及代理之间许多依赖关系的域不适合当今的多代理系统。例如，与研究相比，大多数编码任务涉及的真正可并行化的任务更少，而且 LLM 代理还不擅长实时协调和委派给其他代理。我们发现，多智能体系统擅长处理有价值的任务，这些任务涉及大量并行化、超出单个上下文窗口的信息以及与众多复杂工具的接口。

Research 的体系结构概述
我们的研究系统使用具有编排器-工作程序模式的多代理架构，其中领导代理协调流程，同时委派给并行运行的专用子代理。

当用户提交查询时，Lead Agent 会对其进行分析，制定策略，并生成子代理以同时探索不同的方面。如上图所示，子代理充当智能过滤器，以迭代方式使用搜索工具收集信息，在本例中为 2025 年的 AI 代理公司，然后将公司列表返回给牵头代理，以便其编译最终答案。

使用 Retrieval Augmented Generation （RAG） 的传统方法使用静态检索。也就是说，它们获取一些与输入查询最相似的块，并使用这些块生成响应。相比之下，我们的架构使用多步骤搜索，动态查找相关信息，适应新发现，并分析结果以形成高质量的答案。

为研究代理提供及时的工程设计和评估
多智能体系统与单智能体系统存在关键区别，包括协调复杂性的快速增长。早期的代理会犯一些错误，例如为简单查询生成 50 个子代理，无休止地在 Web 上搜索不存在的来源，以及通过过多的更新分散彼此的注意力。由于每个代理都由提示引导，因此提示工程是我们改进这些行为的主要杠杆。以下是我们学到的提示代理的一些原则：

像您的代理一样思考。 要迭代提示，您必须了解它们的效果。为了帮助我们做到这一点，我们使用控制台使用系统中的确切提示和工具构建了模拟，然后观察代理逐步工作。这立即揭示了失败模式：代理在已经获得足够结果时继续、使用过于冗长的搜索查询或选择不正确的工具。有效的提示依赖于开发一个准确的代理心智模型，这可以使最具影响力的变化显而易见。
教编排器如何委派。在我们的系统中，Lead Agent 将查询分解为 subtask 并向 subagent 描述它们。每个子代理都需要一个目标、一个输出格式、关于要使用的工具和来源的指导，以及明确的任务边界。如果没有详细的任务描述，代理会重复工作、留下空白或找不到必要的信息。我们一开始允许牵头代理给出简单、简短的指示，例如“研究半导体短缺”，但发现这些指示通常非常模糊，以至于子代理误解了任务或执行与其他代理完全相同的搜索。例如，一个子代理探讨了 2021 年的汽车芯片危机，而其他 2 个子代理则重复了调查当前 2025 年供应链的工作，而没有进行有效的分工。
扩展工作量以降低查询复杂性。 代理很难判断不同任务的适当努力，因此我们在提示中嵌入了缩放规则。简单的事实调查只需要 1 个代理和 3-10 个工具调用，直接比较可能需要 2-4 个子代理，每个子代理 10-15 个调用，复杂的研究可能需要 10 多个职责明确划分的子代理。这些明确的指导方针有助于 Lead Agent 有效地分配资源，并防止对简单查询进行过度投资，这是我们早期版本中常见的失败模式。
工具设计和选择至关重要。 代理工具界面与人机界面一样重要。使用正确的工具是有效的 — 通常，这是绝对必要的。例如，代理在 Web 上搜索仅存在于 Slack 中的上下文从一开始就注定要失败。对于允许模型访问外部工具的 MCP 服务器，这个问题会变得更加复杂，因为代理会遇到看不见的工具，这些工具的描述质量参差不齐。我们给代理提供了明确的启发式方法：例如，首先检查所有可用的工具，将工具使用情况与用户意图相匹配，在 Web 上搜索广泛的外部探索，或者更喜欢专用工具而不是通用工具。错误的工具描述可能会使代理走上完全错误的道路，因此每个工具都需要不同的用途和清晰的描述。
让代理商自我提升。我们发现 Claude 4 模型可以成为出色的提示工程师。当收到提示和故障模式时，他们能够诊断代理失败的原因并提出改进建议。我们甚至创建了一个工具测试代理 — 当给定有缺陷的 MCP 工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过对该工具进行数十次测试，该代理发现了关键的细微差别和错误。这一改进工具人体工程学的过程使使用新描述的未来代理的任务完成时间缩短了 40%，因为他们能够避免大多数错误。
从宽处开始，然后缩小范围。搜索策略应反映专家的人类研究：在深入研究细节之前先探索前景。代理通常默认使用过长的特定查询，返回的结果很少。我们通过提示代理从简短、广泛的查询开始，评估可用的内容，然后逐渐缩小关注点来抵消这种趋势。
引导思考过程。 扩展思维模式，引导 Claude 在可见的思考过程中输出额外的标记，可以作为一个可控的便签本。Lead Agent 使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子代理数量，并定义每个子代理的角色。我们的测试表明，扩展思维可以提高指令遵循、推理和效率。子代理还会在工具结果后进行规划，然后使用交错思维来评估质量、识别差距并优化他们的下一个查询。这使得子代理更有效地适应任何任务。
并行工具调用可转换速度和性能。复杂的研究任务自然涉及探索许多来源。我们早期的代理执行顺序搜索，这非常缓慢。为了提高速度，我们引入了两种并行化：（1） lead 代理并行启动 3-5 个子代理，而不是串行启动;（2） 子代理并行使用 3+ 工具。对于复杂查询，这些更改将 Research 时间缩短了 90%，使 Research 能够在几分钟而不是几小时内完成更多工作，同时比其他系统涵盖更多的信息。
我们的提示策略侧重于灌输良好的启发式方法，而不是僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码在我们的提示中——例如将困难的问题分解为更小的任务，仔细评估来源的质量，根据新信息调整搜索方法，以及识别何时关注深度（详细调查一个主题）与广度（同时探索多个主题）。我们还通过设置明确的护栏来主动缓解意外的副作用，以防止代理程序失控。最后，我们专注于具有可观察性和测试用例的快速迭代循环。

有效评估药物
良好的评估对于构建可靠的 AI 应用程序至关重要，代理也不例外。然而，评估多代理系统带来了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 以生成输出 Z。但是多代理系统不是这样工作的。即使起点相同，代理也可能采用完全不同的有效路径来实现他们的目标。一个代理可能会搜索 3 个来源，而另一个代理可能会搜索 10 个，或者他们可能会使用不同的工具来查找相同的答案。因为我们并不总是知道什么是正确的步骤，所以我们通常不能只检查代理人是否遵循了我们事先规定的“正确”步骤。相反，我们需要灵活的评估方法，以判断代理人是否取得了正确的结果，同时也遵循合理的流程。

立即开始使用小样本进行评估。在早期代理开发中，变化往往会产生巨大的影响，因为有大量唾手可得的成果。及时调整可能会将成功率从 30% 提高到 80%。对于如此大的 effect 大小，您只需几个测试用例即可发现更改。我们从一组大约 20 个查询开始，这些查询代表真实的使用模式。测试这些查询通常可以让我们清楚地看到更改的影响。我们经常听到 AI 开发团队延迟创建 eval，因为他们认为只有具有数百个测试用例的大型 eval 才有用。但是，最好从几个示例立即开始小规模测试，而不是等到可以构建更全面的评估时再推迟。

LLM 作为评委的评估量表如果做得好。研究成果很难以编程方式进行评估，因为它们是自由格式的文本，很少有一个正确的答案。LLM 非常适合对输出进行评分。我们使用了一名法学硕士评委，根据评分标准中的标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有请求的方面？）、来源质量（它是否使用了第一手来源而不是低质量的第二手来源？）和工具效率（它是否使用了正确的工具合理次数？我们尝试了多名裁判来评估每个组成部分，但发现单个 LLM 调用和单个提示输出 0.0-1.0 的分数和通过-失败等级是最一致的，并且与人工判断最一致。当评估测试用例确实有明确的答案时，这种方法特别有效，我们可以使用 LLM 判断来简单地检查答案是否正确（即，它是否准确地列出了研发预算前 3 名的制药公司？使用 LLM 作为评委使我们能够大规模评估数百项输出。

人工评估可以捕捉到自动化遗漏的内容。人员测试代理发现 evals 遗漏的边缘情况。这些包括对异常查询的幻觉答案、系统故障或微妙的源选择偏差。在我们的案例中，人工测试人员注意到，我们的早期代理始终选择经过 SEO 优化的内容农场，而不是权威但排名较低的来源，如学术 PDF 或个人博客。在我们的提示中添加源质量启发式方法有助于解决此问题。即使在自动评估的世界中，手动测试仍然是必不可少的。

多智能体系统具有紧急行为，这些行为在没有特定编程的情况下出现。例如，对 Lead Agent 的微小更改可能会不可预知地改变 Subagent 的行为方式。成功需要了解交互模式，而不仅仅是单个座席的行为。因此，对这些代理的最佳提示不仅仅是严格的指示，而是定义分工、解决问题的方法和工作预算的协作框架。要做到这一点，需要仔细的提示和工具设计、可靠的启发式方法、可观察性和紧密的反馈循环。 有关来自我们系统的提示的示例，请参阅我们的说明书中的开源提示。

生产可靠性和工程挑战
在传统软件中，错误可能会破坏功能、降低性能或导致中断。在代理系统中，微小的变化会级联成大的行为变化，这使得为必须在长时间运行的进程中保持状态的复杂代理编写代码变得非常困难。

代理是有状态的，并且错误是复合的。 代理可以长时间运行，在许多工具调用中保持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。如果没有有效的缓解措施，轻微的系统故障可能会对代理造成灾难性的影响。当错误发生时，我们不能从头开始重新启动：重新启动成本高昂且让用户感到沮丧。相反，我们构建了可以从 Agent 发生错误时所在的位置恢复的系统。我们还使用模型的智能来优雅地处理问题：例如，让代理知道工具何时出现故障并让它适应效果非常好。我们将基于 Claude 构建的 AI 代理的适应性与重试逻辑和常规检查点等确定性保护措施相结合。

调试受益于新方法。 代理会做出动态决策，并且在运行之间是不确定的，即使具有相同的提示也是如此。这使得调试更加困难。例如，用户会报告代理“没有找到明显的信息”，但我们不明白为什么。代理是否使用了错误的搜索查询？选择糟糕的来源？击中工具故障？通过添加完整的生产跟踪，我们可以诊断代理失败的原因并系统地修复问题。除了标准可观察性之外，我们还监控座席决策模式和交互结构，所有这些都无需监控单个对话的内容，以保护用户隐私。这种高级可观测性帮助我们诊断根本原因、发现意外行为并修复常见故障。

部署需要仔细协调。代理系统是提示、工具和执行逻辑的高度状态 Web，它们几乎连续运行。这意味着，无论何时我们部署更新，代理都可能在其进程中的任何位置。因此，我们需要防止我们善意的代码更改破坏现有代理。我们不能同时将每个代理更新到新版本。相反，我们使用 rainbow 部署来避免中断正在运行的代理，方法是逐渐将流量从旧版本转移到新版本，同时保持两者同时运行。

同步执行会产生瓶颈。目前，我们的 Lead Agent 会同步执行 subagent，等待每组 subagent 完成后再继续。这简化了协调，但在代理之间的信息流中造成了瓶颈。例如，Lead Agent 无法引导 subagent，subagent 无法协调，并且在等待单个 subagent 完成搜索时，整个系统可能会被阻止。异步执行将启用额外的并行性：代理同时工作并在需要时创建新的子代理。但是这种异步性增加了结果协调、状态一致性和跨子代理的错误传播方面的挑战。由于模型可以处理更长、更复杂的研究任务，我们预计性能提升将证明复杂性是合理的。

结论
在构建 AI 代理时，最后一英里往往成为旅程的大部分。在开发人员计算机上工作的代码库需要大量的工程设计才能成为可靠的生产系统。代理系统中错误的复合性质意味着传统软件的小问题可能会完全使代理脱轨。一步失败可能会导致代理探索完全不同的轨迹，从而导致不可预测的结果。由于本文中描述的所有原因，原型和生产之间的差距通常比预期的要大。

尽管存在这些挑战，但事实证明，多智能体系统对于开放式研究任务很有价值。用户表示，Claude 帮助他们找到了他们没有考虑过的商机，浏览了复杂的医疗保健选项，解决了棘手的技术错误，并通过发现他们无法单独找到的研究联系来节省长达数天的工作时间。多智能体研究系统可以通过仔细的工程设计、全面的测试、注重细节的提示和工具设计、强大的作实践以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的密切合作，可靠地大规模运行。我们已经看到这些系统改变了人们解决复杂问题的方式。

附录

以下是多代理系统的一些其他杂项提示。

在许多回合中改变状态的代理体的最终状态评估。 评估在多轮次对话中修改持久状态的座席面临独特的挑战。与只读研究任务不同，每个作都可以改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现，成功集中在最终状态评估而不是逐向分析上。与其判断代理是否遵循特定的过程，不如评估它是否达到了正确的最终状态。这种方法承认代理可能会找到通往相同目标的替代路径，同时仍然确保他们提供预期的结果。对于复杂的工作流，将评估分解为应该发生特定状态更改的离散检查点，而不是尝试验证每个中间步骤。

长期对话管理。 生产代理经常参与跨越数百个回合的对话，需要仔细的上下文管理策略。随着对话的扩展，标准上下文窗口变得不够用，需要智能压缩和记忆机制。我们实施了代理总结已完成的工作阶段并将基本信息存储在外部存储器中的模式，然后再继续执行新任务。当上下文限制接近时，代理可以生成具有干净上下文的新子代理，同时通过谨慎的交接保持连续性。此外，他们可以从内存中检索存储的上下文，例如研究计划，而不是在达到上下文限制时丢失以前的工作。这种分布式方法可以防止上下文溢出，同时保持扩展交互之间的对话连贯性。

子代理输出到文件系统，以最大限度地减少“电话游戏”。 直接子代理输出可以绕过主协调器以获得某些类型的结果，从而提高保真度和性能。与其要求子代理通过主代理传达所有内容，不如实施工件系统，其中专门的代理可以创建独立存在的输出。子代理调用工具将其工作存储在外部系统中，然后将轻量级引用传递回协调器。这可以防止在多阶段处理过程中丢失信息，并减少通过对话历史记录复制大型输出的令牌开销。该模式特别适用于结构化输出，如代码、报告或数据可视化，其中子代理的专用提示比通过总协调器进行筛选产生更好的结果。

当理想汽车CEO李想将VLA（视觉-语言-动作）模型比作「人类司机」时，行业似乎看到了自动驾驶的终极解决方案。这种整合多模态感知与动作输出的技术框架，确实为机器理解物理世界提供了新路径。但当我们深入剖析自动驾驶的技术本质，会发现VLA模型的光环下，仍存在着难以跨越的工程深渊。

一、被低估的道路博弈论

城市道路是动态博弈的修罗场。每个交通参与者都在进行着纳什均衡计算——行人预判车辆的刹车距离，司机揣摩旁车的变道意图。VLA模型虽能通过视觉识别交通信号灯0，却难以量化人类驾驶者微妙的心理博弈。特斯拉Autopilot在十字路口的「幽灵刹车」现象，正是这种博弈失衡的典型表现。

道路决策树的复杂度远超想象：

1. 基础层：200+交通规则节点（包含各国道路规范差异）
2. 动态层：突发路况的0.3秒决策窗口（如儿童突然冲出）
3. 伦理层：不可避免事故时的道德权重分配

这些层级交织形成的决策矩阵，绝非单纯的「感知-动作」映射能够覆盖。

二、数据闭环的致命缺口

模仿学习的本质缺陷在自动驾驶领域被指数级放大。Waymo最新测试数据显示，即便经过2000万英里的训练，VLA模型在雨雾天气的接管率仍高达0.017%。这个数字意味着，在拥有500万辆自动驾驶出租车的未来城市，每天将发生850起需要人类接管的事故。

更严峻的是数据采集的「科罗拉多悖论」：

当自动驾驶汽车处理完99%的常规场景，剩余1%的corner case需要消耗比之前多100倍的采集成本。这正是当前VLA模型在封闭测试场表现优异，却迟迟无法规模落地的根本瓶颈。

三、安全验证的体系冲突

ISO 26262 ASIL-D标准要求的功能安全，与神经网络的「黑箱」特性形成天然对立。特斯拉Dojo芯片的故障率曲线揭示了一个残酷现实：当芯片规模扩大至5000个计算节点时，年故障率不降反升，达到惊人的117%0。这种指数级增长的故障概率，在生命安全领域是完全不可接受的。

传统汽车电子的「失效-安全」模式（Fail-Safe）在智能驾驶时代遭遇挑战：

四、破局之路：三维评估框架

面对技术狂欢，更需要冷思考。建议构建包含以下维度的新型评估体系：

1. 技术栈融合
   将V2X实时通信协议接入决策环路，使车辆能感知「视觉盲区」外的交通态势。北京亦庄测试区的实践表明，这种车路协同能使决策准确率提升40%。
2. 动态地图机制
   建立分钟级更新的高精地图体系，应对道路临时管制等突发变化。这与特斯拉纯视觉方案的路线形成有益互补。
3. 伦理决策引擎
   开发可解释的伦理权重分配模型，在不可避免事故时实现伤害最小化。德国联邦交通局的「伦理算法白名单」为此提供了参考范式。

当技术突破遭遇工程现实，我们需要清醒认识到：自动驾驶不是简单的「算法迭代」，而是需要整个交通体系的重构。VLA模型或许是重要的技术拼图，但绝不是终局答案。唯有建立兼容技术创新与工程安全的新型评估框架，才能真正推动自动驾驶走向成熟。