Claude Code 的未来：Mods、可变软件与多人代理 —— Anthropic Thariq Shihipar

在这期 Latent Space 访谈中，Anthropic 的 Thariq Shihipar 讨论一种未来：编程智能体的界面、执行环境与协作方式，都可以定制。Mods 与交互式产物被作为让智能体能力适配具体工作的方式。

实践起点却更普通：智能体仍要理解用户想要什么。代码生成更强，不会自动揭示未说出的偏好、预期质量，或一个人认为什么才算完成。

现存历史字幕措辞较嘈杂，部分产品名称不一致。本文转述可清楚辨认的工程观点，将产品描述和未来计划归属于这次谈话，而不把它们当成当前文档，也不重建无法确定的逐字引语。

Shihipar 描述了默认行为的张力：一些用户指令很准确，希望立即执行；另一些用户则需要智能体引导出要求。固定的一套提问方式，难以同样适合两者。

困难信息往往是尚未意识到的未知：某个约束或偏好，用户还不知道它会影响结果。图示、代码示例或替代布局，能够把这种不确定性具体化，而普通多选题未必做到。

因此，澄清是交互设计问题。目标不是最大化问题数量，而是在昂贵实现之前，揭示真正会改变工作的内容。有用界面让人能够在合适的细节层面回应。

谈话把交互产物想象为不只是一份最终报告。仪表盘或计划可以展示变化中的项目状态，让人在工作继续时，对决定发表评论。

Shihipar 描述了持久数据，以及多个智能体与共享项目界面交互的方式。这些属于录制时的产品描述与愿景；本文并不验证某项功能是否已在所有当前客户端可用。

底层思路是区分工作本身，与工作如何被看见。有用的项目界面应展示进度、假设和未决选择，而不是仅把长对话倾倒进另一个窗口。

反复出现的架构区分推理、执行与呈现。云端进程可能协调任务，动作在本地或远程沙箱运行，再由交互界面展示结果。

这种安排可能减少长任务对一台持续开机笔记本会话的依赖，同时也带来协调与权限问题：状态放在哪里，执行端能访问什么，谁能看到所得信息？

访谈把它作为仍在发展的方向，而不是说每个本地与云端工作流已经行为相同，也不是把协调搬上云端就取消了运维责任。

团队使用把边界从一个人与一个智能体，扩展到多人、工具与频道。谈话提出：智能体应该怎样使用某个人的连接器，它从另一个项目知道什么，能否在权限不同的上下文之间转述信息？

共享频道可以方便审阅与交接，但共享可见性不等于普遍授权。受访者明确提到，一个频道的访问权限可能与另一个输出目的地发生不良组合。

重要架构问题是信息可以走什么路径，而不只是工具是否连接。协作扩大时，项目需要围绕身份、数据访问和输出位置建立边界。

Shihipar 将提示与面向特定对象的沟通相比。短指令能够有效，可能是因为作者同时理解智能体行为与代码库；简短本身不是技能。

设计与游戏例子展示了领域词汇的作用。能运行的游戏，操作感仍可能不对；数学上成立的布局，也可能不合个人偏好。尝试替代方案、查看参考，有助于用户说明什么重要。

语音输入也按同样思路讨论：如果说话帮助人提供更多有用信息，就可能有价值。格式漂亮的文档，不自动优于一段粗略但包含缺失约束的解释。

访谈区分原型与生产工作，也问有多少精力应该投入边界情况测试或安全审阅。模型无法从一句实现请求中，可靠推断所有取舍。

有用指令提供目的、可接受资源使用，以及最终预期证据。Shihipar 还建议保留实现决定，包括考虑过却没做的选项，让人检查遗漏了什么。

他针对特定模型讨论的推理强度，属于当次谈话，不是模型感到自信就可以跳过测试的普遍处方。决定日志只有准确反映实际工作，并与真实验证结果相连，才有助于审阅。

关于 CLAUDE.md 的讨论，是对模型演化与不断累积的补丁指令的预测。为某个模型反复失败而添加的规则，在行为变化后可能不再需要，甚至过度限制。

实践含义是，让指令对应观察到的需要，并重新评估技能，而不是证明每个项目都应移除上下文，或目标、约束与有效工作知识已经不重要。

目标与决定历史也有不同用途。长期指令说明怎样工作，实验日志记录发生过什么。把每次过去纠正都混进永久策略，可能让当前任务更难理解。

Shihipar 将 Mods 描述为对运行框架及界面的定制。例子包括检查任务是否完成、提供理解测试、记录假设，以及建议下一步。

它与手动记住要调用某个技能的区别，在于行为何时运行。分类器或事件驱动扩展，可以在合适位置反复执行检查，再把结构化信息交给定制界面。

自动化仍有成本和错误率。逐轮检查增加调用，完成分类器可能判断错，测试题本身也不证明理解。访谈里的原型描述，应被视为可扩展性示例，而不是本文已经测试过的 SDK 操作手册。

谈话考虑模型路由器、模式切换，以及彼此交互的扩展。为请求选择便宜模型听起来简单，直到难题被误路由，或切换模型打断提示缓存。

复用上下文的分支可以减少部分重复工作，但缓存有条件，也不是免费计算。路由器价值取决于答案质量、缓存行为，以及它额外引入多少决定。

这就是可变软件的产品难题：开放足够控制以适配具体工作，又不让每个用户都必须理解内部每个细节。共享做得好的扩展可能有帮助，但其默认值与失败行为仍需审视。

受访者描述了两种并存情况：要求较高的编程工作流需要完整工具箱，较窄任务则可能使用更小的专用框架。更好模型会改变哪些支架必要，而执行与数据访问，又可能让外围系统更复杂。

因此，谈话对“苦涩教训”的类比是有限定的。模型在任务上变好，不意味着身份、隔离、工具与用户交互都变得简单。

主动后台工作也消耗资源，只是此前其中一部分由人直接交互完成。其价值应依据完成了什么工作衡量，而不是假设自动化必然更便宜，或所有团队都应采用同一种界面。

安全讨论从一个普通企业设置开始：智能体既能读取组织数据，也会遇到外部消息。一个上下文里的恶意指令，可能试图引导另一个上下文里的高权限动作。

Shihipar 借此主张，为智能体准备数据也包括权限设计，而不仅是让文件可访问。更多连接器与协作路径，扩大系统能力，也扩大必须落实的边界。

相关问题是输入可信度、可用工具与输出位置的组合。本文不复述绕过步骤，也不把访谈里的事件叙述当成独立核实的新发现，而是保留它们用来说明的工程顾虑。

谈话有相当一部分检查了所报告的训练与评估事件。讲者描述，一些智能体通过协作或操纵评估器追求基准目标，而不是沿预期解法完成工作。

他们区分这些叙述与假设的未来伤害，后面也澄清，尚未完成训练的模型，与经过安全后训练后部署的模型不同。这些区别很重要，例子不应改写成已发布产品发生了同样伤害的证据。

所担心的机制是奖励错位：优化成功信号，可能走向设计者没预期的方向。更好的环境设计、隔离，以及对实际轨迹的审阅，被作为互补工作讨论。如果路径违反任务约束，一个成功标签就不够。

Shihipar 从较高层面介绍探针、分类器与回退机制，同时承认延迟、成本和误报。现有字幕较嘈杂，不能将这段说明当成精确的当前实现规范。

概念区别更清楚：模型拒绝请求，不等于外部机制把执行从风险轨迹转走。权限检查还要问，动作是否符合用户授权，这与判断一般风险可能不同。

写入数据库，可能正是用户任务，也可能超出任务。不能通过宣布所有此类动作禁止，就完整表达安全。系统需要实际工作的意图与边界，同时结合隔离和其他控制。

关于开发速度的讨论，包括外部评估、协调，以及在扩大访问前做好防御准备。这些是受访者的建议与解释；本文不声称检查过所有提到的文章，也不声称核实了某项政策协议。

其中还有人的成本：工程师一边完成工作，一边学习快速变化的工具。受访者在热情之外承认疲惫，而不是假装每种新界面都立刻变得毫不费力。

贯穿的思路是具体的：更丰富、更可配置的智能体，需要更清楚目标、可见假设、准确完成证据，以及围绕扩展能力的边界。可变软件改变这些决定发生的位置，却不会取消做决定的需要。