大家好，我是讯享网，很高兴认识大家。



文中 PPT 由 Nano Banana 生成，关注公众号回复「Claude」即可领取

如果Claude安全哲学与工程奇迹初探（上）主要解释的是 Anthropic 为什么会这样想，那么下篇要看的，就是 Claude 为什么会这样干活。

01

真正让 Claude 在开发者世界里形成口碑的，往往不是参数本身，而是围绕它长出来的一整套工程范式。

讯享网

如果说过去两年 AI 编程最大的关键词是Copilot，那么 2025 到 2026 年更贴切的关键词已经变成了Agent。

这不是简单的产品营销词变化，而是工作范式在变。

传统 IDE 时代，代码几乎 100% 由人写。Copilot 时代，AI 的主要角色是”副驾驶”——帮你补全、建议、续写，效率当然提升了，但主导权仍然在键盘前的人手里。

而 Claude Code 的野心更大。它不是在编辑器里等你叫它补一句，而是直接驻留在终端环境中，变成一个能够自治的工程师。：

读取文件

搜索代码库

执行命令

运行测试

管理 git

小步修改并验证结果

这也是为什么我会觉得，Claude Code 不是”更强补全器”，而是”新的物种”。

它选择 CLI 形态，其实非常有洞察力。因为对很多资深工程师来说，终端才是最强的工作入口：grep、git、npm、pytest、bash、脚本、日志、CI……这些东西天然就是组合式的。Claude Code 不是试图替代这套体系，而是把自己嵌进了这套体系。

你完全可以把它理解为：它不是在重新发明软件工程，而是在给现有软件工程加上一层可执行的智能。

很多人一提 Agent，会先想到”工具调用”。但真正把 Agent 和普通聊天助手拉开差距的，不是会不会调工具，而是能不能形成 Agent Loop 闭环。

Claude Code 背后非常重要的一套逻辑，可以概括为四步：

Explore

Plan

Execute

Verify

也就是：探索、规划、执行、验证。

这四个动作看起来很朴素，但组合在一起，才是智能体真正的骨架。

先探索环境，建立任务上下文；

再做计划，而不是立刻冲上去乱改；

再执行；

最后验证，主动寻找证据证明自己改对了。

这里最关键的有两步。

第一步是Plan。Claude Code 的一个标志性特征，就是它把”先规划、后执行”当成了一种正式模式。这件事非常重要，因为很多早期 AI 编程助手最大的问题就是：写得很快，错得也很快，而且经常一错到底。

第二步是Verify。很多模型会给人一种”它非常自信”的错觉——但自信不等于正确。Claude Code 更有价值的地方在于，它会把测试、日志、验证结果重新纳入工作环，让”完成”尽可能不再依赖嘴上宣布，而是依赖可靠和可信的证据。

这也是为什么我会说：Agent 的核心不在于它能不能输出答案，而在于它能不能把任务做成闭环。

智能体一旦进入真实代码库，马上会遇到两个非常实际的问题：

第一，怎么稳定改代码？

第二，怎么在长任务里不失忆？

前者对应的是精确编辑能力。

相比”把整个文件大段重写”，像str_replace_editor这种机制更有工程味。它要求模型精确定位旧字符串，再替换成新字符串。如果匹配不唯一，或者上下文不够准确，就拒绝执行。这种设计本质上是在强迫模型对当前文件状态保持更高的敬畏感。

说得直白一点：越是强的 Agent，越不能让它”想当然地乱改”。

后者对应的，就是Context Engineering。

大模型哪怕有 200K、1M 的上下文，也不是无限的。真正的难点不是”窗口够不够大”，而是：什么信息值得留在窗口里。

Anthropic 在这方面的思路很有代表性。

一个是CLAUDE.md。你可以把它理解为 AI 的项目员工手册：

项目有哪些常用命令

有哪些架构规范

哪些坑以前踩过

哪些经验是团队共识

这不是普通文档，而是一种持久上下文。

另一个是compaction，也就是上下文压缩与摘要机制。它背后的理念也特别好：有损压缩，无损意图。

意思是，可以丢掉冗余过程，但不能丢掉关键决策、任务状态和真正重要的约束。

这也是为什么我认为，上下文工程很可能会成为未来几年最被低估的新能力之一。以前大家比的是”谁更快写出算法”；未来大家更可能比的是：谁更会为智能体搭建一个高质量的上下文环境。

如果说 Claude Code 让很多人第一次觉得”AI 已经能写不少真实代码”，那么Claude Code Security则把这个想象又往前推了一步。

它的意思不是”AI 会扫描几个漏洞规则”，而是让 Claude 用一种更接近安全研究员的方式去理解代码：追踪数据流、理解组件关系、判断复杂逻辑漏洞，并在多阶段验证之后给出补丁建议。

这件事的意义非常大。

因为传统安全扫描很擅长抓”已知模式”，但面对业务逻辑漏洞、复杂权限绕过、上下文相关问题时，经常力不从心。Claude Code Security 则代表了另一条路：不是只找固定模式，而是让模型像人一样去读、去推理、去验证。

它仍然需要人类审核，这一点非常重要。Anthropic 也明确强调，最终决定权仍然在开发者手里。可即便如此，它已经说明一件事：AI 在工程里的角色，正在从”生成代码”延伸到”审视代码、改进代码、保护代码”。

从商业层面看，这也解释了为什么安全行业会对它高度敏感：一旦 AI 能真正介入漏洞分析和修复建议，很多传统安全工具的价值边界都要被重新定义。Claude Code Security 发布后网络安全股遭遇大幅抛售，总市值一夜蒸发超100亿美元，这就是来自市场的预判。

所以我真正要说的不是Claude Code 强无敌，而是：软件工程正在从”副驾驶辅助你开车”，变成”你开始管理一位乃至多位真正会干活的智能体同事”。

---

02

当模型开始接世界、调工具、沉淀经验，智能体才真正从”会说”变成”能做”。

大模型进入真实世界后，很快就会遇到一个限制：光会说，不够。

它必须能调函数、读文件、查网页、跑代码、接业务系统、操作工具，才能真正参与工作。

早期大家更熟悉的概念是Function Calling。模型输出函数名和参数，外部程序去执行。这个机制非常重要，因为它第一次把”模型输出自然语言”变成了”模型触发系统动作”。

但很快，行业意识到这还不够。

原因很简单：现实世界里的工作，不是一次调用一个函数就完事。它经常需要多个工具、多步协作、不同来源的信息组合，以及更复杂的控制策略。

于是，Tool Use的意义就出现了。

它不是 Function Calling 的替代品，而是一个更大的框架。你可以把它理解为：Function Calling 解决”模型能不能调用工具”，Tool Use 解决”模型怎么组织工具生态来工作”。

当工具类型从单一函数扩展到：

Function

Code interpreter

File search

Web search

MCP

Computer use

模型的角色就开始变化了。它不再只是回答问题，而是在规划一套动作链。

AI 界的 Type-C，这不是一个为了传播方便的比喻，而是相当准确的工程类比。

过去每个模型、每个应用、每个数据源都要彼此单独打通，复杂度会迅速膨胀。三个模型乘四个数据源，就是十二套集成。再往上，只会越来越乱。

MCP 的思路，就是在模型和外部系统之间插入一个统一协议层。

这样做的好处是：

模型不需要逐个适配每个系统；

工具提供方也不需要为每个模型重写一遍接口；

数据、动作、模板，都可以在同一套协议里被管理。

MCP 里最核心的三个原语是：

Tools：可执行动作

Resources：可读取数据

Prompts：可复用模板

一旦你从这个角度看，就会明白 MCP 的本质不是”又一个工具”，而是一种把模型与外部世界解耦的连接标准。

这也是为什么它对企业场景尤其重要。数据库、内部 API、业务系统、文档中心、审批流，都可以通过 MCP 统一接进来，权限、审计和治理也更容易集中处理。

即便有了工具调用和 MCP，问题也还没结束。

因为现实任务里，还有一个被大量低估的成本：中间结果太多，推理轮次太多。

这就是PTC，也就是程序化工具调用要解决的问题。

传统方式下，模型经常会陷入一种”乒乓球效应”：

调一次工具

把结果塞回上下文

再推理一次

再调下一次工具

再把结果塞回上下文

如果任务稍微复杂一点，几十轮来回就会把延迟、成本和上下文污染一起拉高。

PTC 的思路更像工程师：不要靠自然语言一轮一轮问，直接写个脚本把事做完。

让 Claude 生成 Python 脚本，在沙箱里执行：

循环

条件判断

排序过滤

错误处理

数据转换

都在代码里做，最后只把真正需要的结果送回上下文。

这背后有两句特别值得记住的话：

Compute over Context

Coding as Reasoning

意思很简单：能用计算解决的问题，就别全堆进上下文里；能通过程序结构表达的推理，就别全靠自然语言硬想。

这其实也是 Anthropic 整体工程哲学的一部分：让概率模型，尽可能工作在一个更确定的执行环境里。

如果说 MCP 解决的是”怎么接入世界”，PTC 解决的是”怎么高效执行”，那么Skills解决的，就是另一个更容易被忽视的问题：

经验如何复用？

真实工作里，很多事情不是”不会做”，而是”每次都得重新想一遍怎么做”。

团队 SOP、文档模板、**实践、边界处理、行业习惯，这些东西如果只存在专家脑子里，AI 再强也很难稳定复现。

Skills 的意义，就是把这些经验打包成一个可以按需加载的知识胶囊。

它的最小形态甚至很简单：一个SKILL.md文件，就可以定义这个技能是什么、适合解决什么问题、能调用哪些工具、要注意哪些边界。

更妙的是，它采用的是渐进式披露：

先只加载目录级元数据

需要时再读完整 Skill 定义

真正执行时才去读模板、脚本、示例

这就避免了一个大问题：上下文污染。

很多人第一次接触 Agent 时，会下意识想把所有经验都塞进系统 prompt 里。但这种做法很快就会失控。Skills 的思路更工程化：让知识像模块一样，按需加载，而不是全量灌输。

关于 Skill, MCP 和 PTC，我个人是这么理解的他们的三层关系的：

Skills：认知供给层，解决”怎么做”

MCP：连接层，解决”能用什么工具”

PTC：执行层，解决”如何高效执行”

当这三者组合起来，Agent 才不再只是会说会调工具，而开始具备真正的可复用性。

未来真正拉开差距的，不只是模型谁更强，而是：谁能把工具、数据、模板、SOP 和专家经验变成一个可持续复用的系统。

连接决定边界，执行决定效率，而经验复用决定规模。

---

03

如果只用一句话总结 Anthropic，我更愿意说：它真正特别的地方，不是把模型做得更像人，而是把智能做得更像系统。

它把很多公司分开处理的几件事，硬是拧成了一根绳：治理、安全、可解释性、工具接入、经验复用。于是 Claude 的竞争力，也不再只是”回答更好”，而是”工作得更稳”。

这可能就是大模型下一阶段最清晰的分水岭，不是谁更会聊天，而是谁更能被监督、被接入、被验证，也更能在真实环境里持续产出结果。

未来已来，只是分布不均。***的版图已经展开，愿所有提前入局的探索者，都能在这里精准锚定未来的坐标。