标签归档：AI 编程

AI Coding 时代如何有效度量研发效能

在 AI Coding 时代，当我们说提升效能 50%，从老板的角度，那应该要干掉 50% 的人。

但又不能真这么干，这是一个简单的财务逻辑，也是一种本能的反应。

但研发又不是完全标准化的流水线。AI 在各环节都有提速，但对于需求理解的一致性，线上兜底，发布治理这些环节没法完全同步提速。

人是可以砍，但最终系统脆弱性、技术债务和交付风险一起放大。

以 AWS 为例，公众知道的类似线上故障发生不止两次了。

并且在一些大的公司，也出现了开发人员不知道自己写的是什么的情况，对于大公司一套巨大的工程体系，如果是一个完全的黑盒，没有人知道里面发生了什么，出现大的问题只是迟早的事情。

聊远了点，回到今天的主题，如何有效的度量研发效能。

当我们用上 AI Coding 之后，在上面所说的整体提效的逻辑中，我们需要细化这个效能的度量逻辑。

同样规模的团队，能不能交付更多有效价值，能不能把交付周期压短，能不能在不明显增加事故和历史债务的前提下，把过去做不到的事情做起来。

从指标的逻辑来看，DevOps 里那套大家已经很熟的「四个指标」——部署频率、交付周期、变更失败率、平均恢复时间依然是很能打的一组指标。尤其是 TTM，也就是从需求进入系统到真正产生用户价值的时间，还是王牌指标。

AI 时代，研发效能的核心指标体系要刷新，但不能推倒重来。

整个度量的逻辑不仅仅在于指标，同时也在于到底把指标绑在什么对象上，怎么解释，怎么防止它们被 AI 放大之后失真。

度量谁

一个问题，AI 产出要不要单独度量？

建议是：可以记录，不要单独考核。

因为 AI 没有责任主体。它不会背 SLA，不会参加事故复盘，也不会在需求失败时承担后果。

如果我们把「AI 生成代码占比」或者「AI 采纳率」当核心 KPI，很快就会把团队带进一个很熟悉的坑：为了优化指标而优化行为，最后牺牲真实交付质量。

研发效能度量一定要有清晰主体。这个主体通常有三层：

  • 工程师个体
  • 团队
  • 价值流或产品线

在 AI 时代，我更建议把主分析单位放在团队和价值流，但个体数据也需要通晒，人与人还是需要比较，并且人的实际使用情况也需要观测和度量。

说到个体度量，可能会有人觉得开始卷了，回到了粗暴管理

我觉得个体数据要看，并且要公开到一定程度。否则团队里谁在真正把 AI 用进生产，谁还停留在传统写法，谁能稳定地产出高质量变更，谁在用 AI 快速制造垃圾代码，管理层根本看不见，辅导也无从下手。问题从来不在于能不能比较，问题在于拿什么比较，以及比较之后准备用它干什么。

可以把「个体可观测」和「个体直接考核」分开。前者要做细，后者要克制。个体层的数据主要解决三类问题：第一，识别使用差异。第二，识别能力短板。第三，识别风险人群。比如有的人 AI 使用频率很高，但交付周期没有改善，返工率还在上升，这通常不是工具问题，是任务拆解、约束描述、结果校验出了问题。还有一种人，表面上 AI 使用不多，但需求稳定、事故极少、关键模块掌控力强，这类人往往承担了大量隐性复杂度，单纯看「人均产出量」会被严重低估。

所以个体层该看的，不是「生成了多少」，而是「借助 AI 之后，个人交付行为发生了什么变化」。可以重点盯几组数据：需求从领取到合并的中位时长、PR 平均大小、评审往返次数、回退率、线上问题关联率、测试补充情况、跨模块变更占比、AI 建议采纳后的修改幅度。这里面真正有价值的，不是某个数字本身，而是前后变化和人与人之间的分布差异。一个人 AI 采纳率高，不说明他强；采纳率高、评审一次过、上线后稳定，这才说明工具真的转化成了产能。反过来，另一个人采纳率也高，但 PR 越来越大、review 来回打架、上线后热修频繁，这种数据就已经在报警了。

个体数据为什么要通晒？

团队协作里，很多能力本来就是相对的。谁的需求吞吐稳定，谁总能把复杂变更压在可控范围里，谁的变更老是把测试链路打爆，谁对 AI 的依赖已经超过了校验能力，这些不能永远藏在「一团和气」后面。通晒的价值是建立真实参照系。工程团队里最怕的一种状态，是大家都觉得自己做得差不多，实际上产出质量、稳定性、问题密度差了一倍以上。数据如果不拉平，组织就只剩印象管理。

当然，个体通晒有前提。第一，口径必须统一。第二，不能只晒单一指标。第三，必须配上下文。比如一个人长期负责遗留系统改造，变更失败率高一点、交付周期长一点，很正常；另一个人长期做边缘功能，吞吐高也不稀奇。脱离任务难度做横向比较，最后一定会逼着大家抢简单活。我的经验是，个体层至少要把任务类型、系统风险等级、需求大小这几个维度一起带上。不然表面上是在做精细化管理，实际上是在奖励投机。

团队层和价值流层还是主轴，因为真正的交付结果最终只能在这两层闭环。一个工程师再强，也没法单独决定发布窗口、联调效率、测试环境、跨团队依赖和灰度策略。AI 时代尤其如此。代码写快以后，瓶颈更容易从个体编码能力转移到团队协作和系统机制上。所以如果一个团队整体 TTM 没降、变更失败率在升、MTTR 也没有改善，那就算团队里有几个人个体数据很亮眼，也不能说明这个组织真的变快了。很多管理者容易被「明星工程师 + AI」的局部高产迷惑，这是很危险的。效能度量最终看的是系统，不是看谁在局部冲得猛。

价值流这一层更关键，因为它决定了管理层看到的是局部繁荣，还是真实效率。一个需求从业务提出到用户可用，中间穿过产品、研发、测试、运维、合规、数据、客服，任何一个环节卡住，前面所有 AI 提速都白搭。很多团队以为自己效能不差，问题出在开发不够快；把价值流拉直一看，开发可能只占整个周期的 20%。剩下 80% 都耗在等待、确认、返工和协调上。这个时候你还在研究个人 AI 采纳率有没有上去，说实话，方向已经偏了。

所以，三层都要度量，但角色不同。

  • 个体层，解决的是识别差异、暴露问题、推动辅导。
  • 团队层，解决的是交付责任和工程能力。
  • 价值流层，解决的是端到端效率和组织瓶颈。

如果非要再说得更落地一点，可以这样处理：

  • 个体层数据全量采集，有限通晒，谨慎用于绩效
  • 团队层数据作为正式经营指标，进入月度复盘
  • 价值流层数据进入管理层决策，用来推动跨部门改造

这里还有一个问题：AI 使用情况本身，确实会逐渐演化成个体能力差异的一部分。今天还可以说是工具习惯差异，再过一段时间，它会越来越接近工程生产方式差异。有人能用 AI 快速完成问题拆解、方案比选、代码生成、测试补全、文档整理，再自己完成严格校验；有人只是把 AI 当高级补全，甚至生成什么就提交什么。两者的产出质量和成长速度，一定会拉开。这个差异如果不观测，组织是在主动放弃识别新能力结构的机会。

还是那句话，观测不等于迷信，比较不等于唯排名论。个体层数据要服务于两件事：培养更强的人，提前发现风险。它不能把团队带回那种老派的、只会按数字压人的管理习惯。因为 AI 时代最不缺的，就是表面上很漂亮的数字。真正缺的，是能把这些数字放回具体工程语境里解释清楚的人。

量结果

我一直不太赞成把研发效能拆成「过程指标 vs 结果指标」两个完全对立的东西。工程里没这么清楚。很多大家嘴里的结果指标，实际上掺了很多过程含义。代码行数就是典型例子。

很多人说 LOC 已经过时，这话只说了一半。更准确一点：LOC 从来就不是好的一线效能指标，在 AI 时代更差。

原因有三个。

  • 生成成本塌了：过去一个人写 500 行和写 50 行，投入成本通常不同。现在 AI 补全、生成、重构、搬迁代码，几分钟就能吐出成百上千行。代码行数和人类投入的相关性被打穿了。
  • 噪音变大：AI 很容易生成「看起来很完整」的实现：参数校验、日志、适配层、重复样板、冗余抽象全都给你带上。LOC 涨得飞快，但业务价值未必增加。
  • 债务被掩盖：最麻烦的是第三点。AI 会让代码库存增长速度明显快于架构治理速度。表面上看，产出变高了；往后看，维护成本、理解成本、回归成本都在涨。LOC 会把这个问题盖住。

所以代码行数其实没有啥意义，只当成代码影响范围的辅助信号，别当产出指标。

那真正该量什么结果？

可以分三类。

交付结果

这是最基础的一层：

  • 需求交付数量
  • 需求交付周期
  • 按期上线率
  • 有效发布次数
  • 版本回退率

这里要提醒一下：上线需求数也很容易失真。
因为需求切得越碎，上线数越好看；但碎到一定程度，用户感知价值可能没有提升，反而多了协调成本。

所以需求数量一定要配合需求粒度标准化。最少要把需求分成几类：小修复、小功能、中型功能、跨系统项目、技术治理项。不同类型分开统计，不然一张表里什么都看不出来。

业务结果

如果团队做的是业务研发，最终还是得往用户影响上落。常见的：

  • 某类功能从提出到用户可用的时间
  • 用户覆盖范围
  • 功能使用率
  • 转化率变化
  • 关键漏斗改善
  • 客诉下降
  • 线上稳定性对收入的影响

很多技术管理者不敢碰业务指标，怕研发背锅。我反而觉得该看，但不要简单归因。业务结果可以做关联分析，不要粗暴做责任归因。比如某个推荐功能两周上线了，但实验效果一般，这不等于研发效能差。研发效能差，应该体现在 TTM 过长、试验成本过高、回滚困难、迭代慢，而不是实验结论本身不好。

工程结果

如果团队做的是平台、基建、中间件、工具链，不能硬套 GMV、转化率这种业务指标。这个场景下我更看这些：

  • 接入团队数
  • 接入周期
  • 平台能力调用成功率
  • 构建时长变化
  • 测试时长变化
  • 故障发现提前量
  • 资源成本变化
  • 事故数和事故影响面
  • 研发人均可支撑服务数

基建团队最吃亏的一点，是价值释放往往滞后，而且分散在别人的效率提升里。如果你只盯上线需求数，这类团队会被系统性低估。

TTM 还是核心指标

如果只能保留一个指标，我还是会选 TTM。

这里说的 TTM，不是立项到上线的日历时间，而是价值从进入研发系统到到达用户手里的有效时间。很多公司嘴上讲敏捷，实际上量的是开发开始到提测结束，这根本不是 TTM。

为什么 TTM 在 AI 时代更重要？

因为 AI 最直接改变的，就是局部生产速度。代码写快了，单测补得快了，文档初稿也快了。问题是，这些加速会不会真的传导到业务价值交付，完全不确定。

我见过最典型的一种情况：

  • 开发编码时间下降 40%
  • PR 数量上涨 2 倍
  • 评审负担上涨 60%
  • 测试回归时长上涨 35%
  • 发布前冻结窗口变长
  • 最终需求上线周期几乎没变

如果你只看编码侧的数据，会得出一个完全错误的结论：AI 大幅提升了效能。
如果你看 TTM，问题一下就暴露了：加速发生在局部，瓶颈转移到了下游。

所以 TTM 的价值就在这里。它不关心你用了什么先进工具，它只看最终有没有把价值更快交出去。

TTM 怎么拆

TTM 不能只看一个总时长，否则只能看热闹。要拆段看：

  • 需求澄清耗时
  • 方案设计耗时
  • 开发耗时
  • 评审耗时
  • 测试耗时
  • 等待发布耗时
  • 灰度验证耗时

拆完之后，你才知道 AI 真正帮到了哪一段，堵在了哪一段。

另外，在 AI 时代，这种拆段是否合理，是否可以合并不同阶段或角色，让一些信息的流转内化为个人的思考逻辑，实现端到端的 AI 化。

比如，产品经理直接从需求到前端代码的实现。

看分布，不看均值

TTM 最忌讳只看平均值。平均值非常会骗人。正确看法至少要有：

  • P50
  • P75
  • P90
  • 超过阈值的长尾需求占比

因为 AI 往往会优先优化简单需求。这样 P50 可能很好看，P90 反而更差。原因也简单，简单需求被快速吞掉之后，系统里剩下的都是复杂需求、遗留系统改造、跨域联动项目，长尾会更长。

如果你只看均值，会误判整个系统在变快。

四个指标

DevOps 四指标在今天依然能打，但口径需要有一些升级。

部署频率

部署频率比 LOC 强太多。因为它至少是靠近真实交付动作的。代码写了多少行没人关心，真正有意义的是你有没有把变更安全地推到生产环境。

但部署频率也不能裸看。

高频不等于高效

AI 上来之后，一个常见变化就是团队更愿意切小 PR，发小版本。这个方向本身没问题，小批量交付通常更安全。问题在于，有些团队把一个正常需求拆成大量低价值、低独立性的碎发布，频率上去了，用户价值没上去，测试和发布成本反而更高。

所以我一般会同时看三个维度：

  • 单位时间部署次数
  • 每次部署的有效变更量
  • 每次部署的独立可验证价值

没有后两项约束，部署频率很容易变成表演数据。

适用场景不同

业务团队和基建团队的部署频率口径也不能完全一样。

业务团队可以看：

  • 每周或每日生产发布次数
  • 灰度发布次数
  • 从功能完成到触达用户的次数

基建团队更适合看：

  • 核心服务变更发布频率
  • 非工作时段紧急发布占比
  • 配置变更自动化发布比例
  • 平台工具链版本迭代频率

基建团队很多时候更强调稳定和兼容，追求极端高频未必合理。比如数据库、中间件、网关这类系统，频率太高反而可能说明变更管理有问题。

交付周期

交付周期本质上是 TTM 在工程流水线里的展开版。通常从代码提交到生产运行，也有人从需求进入开发开始统计。具体口径可以按团队定，但必须固定。

AI 时代交付周期最容易出现两个假象。

  • 提交变快了，交付没变快： 这是前面说的局部提速问题。AI 让提交更快，但后续验证没跟上，周期不会实质下降。
  • PR 变多了，周期看起来更短：如果团队把一个需求拆成多个极小 PR，每个 PR 周期都很短，报表会很好看。但从需求视角看，整体仍然很慢。所以我建议同时维护两套口径：一个是 PR 级交付周期，另一个是需求级交付周期。PR 级用于观察工程流水线摩擦，需求级用于看真实业务交付。只看其中一个，都会失真。

变更失败率

这个指标在 AI 时代的重要性实际上上升了。

因为生成式编码提高了变更速度，也提高了「错误以正确形式出现」的概率。以前很多错误是写不出来，现在是能很快写出一个逻辑闭环、风格统一、还能过部分测试的错误实现。它更隐蔽，也更容易通过表面检查。

可以把变更失败率定义得更工程化一点，至少包含这些事件：

  • 发布后触发回滚
  • 发布后引发 Sev 事故
  • 发布后触发热点修复
  • 发布后造成核心指标异常
  • 发布后引起客户可感知故障

如果定义太窄，只算重大事故，这个指标会钝化。定义太宽，又会把正常试错算进去。团队需要自己定边界，但边界一旦定了就别频繁改。

AI 对失败率的影响机制

这里有几个常见来源：

  • 生成代码对边界条件覆盖不足
  • 引入不必要抽象，增加理解偏差
  • 与历史代码风格和隐式约束不一致
  • 测试代码同样由 AI 生成，出现「同源缺陷」
  • 变更面比工程师主观预期更大

我自己比较警惕第四点。很多团队现在喜欢让 AI 顺手补测试，看起来很完整。但如果实现和测试都建立在同一段错误理解上，测试通过并不能证明正确。

所以在高风险变更里，测试不能只依赖生成。关键路径一定要有人做反例设计。

平均恢复时间

很多团队对 MTTR 的重视程度不够，尤其是业务团队。实际上，AI 时代恢复能力的重要性在上升。

当代码生成速度变快，进入生产环境的变更更多、更碎、更频繁，系统面对故障的概率和复杂度都在变化。你不一定能把每次变更都做得完美，但你必须能快速止血。

MTTR 的价值在于衡量团队是否真正具备工程韧性。这个指标背后对应的是一整套能力：

  • 监控和告警是否有效
  • 变更是否可追踪
  • 是否支持快速回滚
  • 灰度和开关能力是否完善
  • 值班机制是否靠谱
  • 故障定位信息是否充分

很多团队前面三个指标都好看，MTTR 很差。这样的系统经不起规模化 AI 变更。因为一旦出事，恢复慢会把前面所有频率和周期优势全吃掉。

历史债务

AI Coding 真正会在一年后把团队拉开差距，这里的差距在于谁更早处理历史债务。

这个问题现在还没有被足够重视。但是实际中已经越来越严重了。

因为短期内 AI 会制造一种繁荣感：交付更快，PR 更多，需求吞吐上升。可如果代码库质量、模块边界、测试资产、文档一致性没有同步改善，债务会以更快速度积累。

AI 会怎样放大债务

几个很典型的模式。

  • 重复实现增多：工程师直接让 AI 在局部上下文里生成功能，很容易绕过现有抽象和公共能力。短期最省事，长期就是重复轮子到处长。
  • 中间层膨胀：AI 很擅长生成 adapter、wrapper、facade 这类看起来规整的中间层。问题是很多层根本没有必要，只是为了让局部代码更顺。半年后系统会变得非常厚，排障和重构都很痛苦。
  • 测试资产劣化：生成测试很快，真正有效的测试不快。团队如果只追求覆盖率，很快就会积累大量低价值测试：断言脆弱、依赖实现细节、执行慢、维护成本高。最后 CI 时间越来越长，大家开始跳过测试。
  • 文档与实现漂移更快：AI 可以快速生成设计说明、变更记录、接口文档初稿。但只要流程里没有强约束，这些文档过几周就过时。文档数量增加，不代表知识管理更好。
  • 债务怎么量：技术债务很难精确，但不代表不能量。至少看四组信号：

    • 重复代码比例或重复能力点数量
    • 关键模块复杂度变化
    • 测试执行时长与稳定性
    • 历史模块变更失败率和恢复时长

指标落地

说一堆指标，如果最后只是做一张月报，那基本没用。研发效能度量要落地，大概可以看三点：统一口径、自动采集、和决策绑定。

统一口径

很多团队最大的问题不是没数据，是每个人嘴里同一个词代表不同意思。

比如「交付周期」，有人从排期开始算，有人从开始开发算，有人从代码提交算。你拿这三种数据做横向比较，结论一定错。

所以第一件事就是给每个指标下工程定义：

  • 起点是什么
  • 终点是什么
  • 谁负责标记状态
  • 异常情况怎么处理
  • 统计周期是什么
  • 看均值还是分位数

这一步很枯燥，但躲不过去。没有口径统一，报表越华丽越危险。

自动采集

凡是靠人手填的效能数据，最后都会漂。

我建议优先从这些系统自动取数：

  • 需求系统
  • Git 仓库
  • CI/CD 平台
  • 测试平台
  • 线上监控与事故系统
  • 发布平台
  • 值班和告警系统

AI 时代还可以补一些辅助数据，比如：

  • AI 建议采纳率
  • AI 生成代码在最终提交中的占比
  • AI 相关变更的回退率
  • AI 生成测试的失败分布

但这些只建议做诊断维度，不建议直接进核心看板。

和决策绑定

指标如果不进入真实决策流程，就只会变成汇报材料。

可以把不同指标绑定到不同节奏：

周维度

团队看流水线摩擦：

  • PR 周期
  • 构建失败率
  • 测试时长
  • 发布次数
  • 热修次数

月维度

管理者看交付和稳定性：

  • TTM 分布
  • 部署频率
  • 变更失败率
  • MTTR
  • 技术债务信号

季度维度

看结构性问题：

  • 跨团队依赖导致的等待占比
  • 核心系统复杂度变化
  • 自动化覆盖关键路径的比例
  • 平台能力复用率
  • 人均支撑规模变化

只有当指标驱动了人力投入、架构治理、流程调整，度量才算产生价值。

常见误区

  • 误区一： 拿 AI 使用量替代研发效能。 比如：人均每天调用 AI 多少次，AI 生成了多少代码，采纳率多少，这些数据可以看工具渗透率，不能代表团队变快了，更不能代表交付变好了。高采纳率有时候只是因为团队在写更多样板代码。
  • 误区二：把效能问题当管理问题。 一看到周期长，就加日报、加审批、加同步会。这个思路在 AI 时代更危险，因为编码加速之后，组织摩擦会成为主要瓶颈。继续加管理动作，只会让非编码时间更长。效能最后还是要回到工程根上：架构边界、测试自动化、环境一致性、发布能力、可观测性、模块治理。
  • 误区三：把所有团队放在一套指标下排序。业务、基建、平台、安全、数据团队的工作性质差异很大。统一看板可以有，统一排名很容易把组织带偏。
  • 误区四：只看短期提速，不看长期维护成本。 AI 最容易制造的错觉就是这个月吞吐上涨了，于是大家默认效能提升。可如果未来三个月回归变慢、故障变多、重构困难，这个月的漂亮报表只是透支。
  • 误区五：只看平均值。平均值会把长尾、异常、结构性阻塞全部抹平。工程管理里，很多真正该解决的问题都藏在 P90 之后。

最后

研发效能从来不是一个分数问题，它是一个约束系统问题。得回答下面的问题：

  • 价值有没有更快交出去
  • 变更是不是足够安全
  • 出问题能不能快速恢复
  • 现在的速度有没有透支未来

这四件事里，TTM 仍然是排第一的。因为业务不会为你写了多少代码买单，也不会为你调了多少次 AI 买单。业务只关心一件事：价值多久能到用户手里。

AI Coding 改变了工程生产函数。

但它没有改变研发效能的基本物理规律。局部速度不等于系统速度，生成能力不等于交付能力，短期吞吐不等于长期效率。

不要急着发明一套全新的效能宗教。先把工程里的主干指标守住，把主体放对，把业务团队和基建团队分开看，把技术债务纳入视野，再去观察 AI 到底在哪些环节真的创造了增益。

这样量出来的数据，才能指导决策。否则报表再热闹，也只是另一种噪音。

以上。

作为 CTO，应该如何看待 AI 编程

前段时间和几个技术圈的朋友吃饭，聊到最近很火的 AI 编程工具（Cursor 估值近百亿），大家的深入程度都各不相同。有人已经把 Cursor 当成标配，离了它写代码都不太行；有人还在观望，觉得这玩意儿不太靠谱；有人在团队内小范围试点，看一看；有人怕有风险，不敢在团队内推广（不仅仅是安全风险，还有组织内部的一些问题）。

作为技术负责人，面对 AI 编程这个话题，确实挺纠结的。一方面，这东西确实能提效（但不能只盯着提效这个逻辑），另一方面，各种担心也不是空穴来风。今天想聊聊，站在 CTO 的角度，到底该怎么看待和处理这个事。

先说说目前我观察到的几种典型态度。

四种常见的应对策略

第一种是ALL IN 派。这一派通常有几个特征：要么是连续创业者出身，习惯了快速试错；要么是 AI 的忠实信徒。在性格上，他们会偏向冒险一些，相信「天下武功唯快不破」。

从公司规模来看，这种策略多见于 50-200 人的成长期公司。为什么？因为这个阶段的公司正处在生死时速，既有一定的资源去尝试新东西，又还没有大公司那么多条条框框。CTO 往往直接向 CEO 汇报，有较大的决策权。他们的逻辑很简单：如果 AI 真能让研发效率翻倍，那就是弯道超车的机会。

但这种激进往往源于一种可能被时代抛弃的焦虑。刚经历过移动互联网时代的洗礼，深知错过风口的代价。所以看到 AI 编程工具，第一反应就是不能再错过了。

第二种是坚决抵制派。这一派往往技术功底深厚，可能是从程序员一路做上来的。他们可能写过操作系统，造过各种轮子，对代码有种近乎偏执的掌控欲。在他们眼里，让 AI 写代码就像让机器人替你谈恋爱，总觉得少了点什么，没有灵魂。

并且这种策略常见于两类公司：一是金融、医疗等强监管行业的大公司，动辄上千人的技术团队，任何技术决策都如履薄冰；二是某些技术驱动的独角兽，公司文化中有很强的工程师自豪感，「我们的代码都是艺术品」。

换个角度看，这种抵制其实是一种保护。保护什么？保护既得利益，保护现有体系，更重要的是保护自己的价值认同。当你花了二十年时间成为编程高手，突然有人告诉你 AI 十秒钟就能写出差不多的代码，这种冲击是巨大的。抵制，某种程度上是在对抗这种价值崩塌。

第三种是建立预期后科学推广。这一派通常是职业经理人出身，可能有 MBA 背景，擅长做 PPT 和汇报。他们的特点是理性、谨慎、程序正义。什么事都要有方法论，有流程，有数据支撑。

这种策略在 500-2000 人规模的成熟公司可能会比较常见。为什么？

因为船大难掉头。这个体量的公司，往往已经有了完整的研发流程、质量体系、安全规范。任何新工具的引入都需要考虑对现有体系的影响。CTO 的 KPI 里，「稳定」的权重往往大于「创新」。

但问题在于，「科学」有时候会变成「科学主义」。制定了详尽的试点方案，设计了完美的评估指标，组织了多轮评审会议，最后发现三个月过去了，还在讨论试点范围。等到真正推广的时候，市场上已经有更新的工具了。这种「理性」背后，其实是一种精致的不作为。

第四种是躬身入局派。这一派有个特点：有比较强的好奇心。他们是一些爱折腾的技术。看到新工具，第一反应不是评估风险或收益，而是「让我试试看」。

这种人通常出现在两种场景：一是 20-50 人的初创公司，CTO 还在一线写代码，甚至就是技术合伙人；二是某些特别重视技术文化的中型公司（200-500人），虽然 CTO 不用写生产代码了，但还保持着 hands-on 的习惯。

其实，这一派的逻辑很朴素：没有调查就没有发言权。与其听别人说，不如自己试。这种实用主义的背后，往往是对技术的真正热爱和对未知的好奇。他们不会被各种宏大叙事忽悠，也不会因为恐惧而止步不前。

无论采取哪种策略，团队里总有人在用 AI 写代码。就像当年公司禁用 QQ，大家就用网页版；禁用网页版，就用手机。技术的渗透往往是自下而上的，任何自上而下的管控都可能流于形式。

需要考虑的核心问题

站在 CTO 的位置，引入 AI 编程工具不是简单的技术选型，而是一个系统性决策。至少要考虑这几个维度：

成本问题。表面上看，AI 工具能提高编码效率，降低人力成本。但别忘了，工具本身也要钱。Cursor 企业版每人每月 40 美元，且高级模型大概率是不够用的，全公司算下来也是笔不小的开支。更重要的是隐性成本：代码质量下降带来的维护成本、安全漏洞带来的修复成本、团队能力退化带来的长期成本。

安全问题。这可能是大家说得最多的问题。你的代码会不会被上传到 AI 服务商的服务器？会不会被用来训练模型？竞争对手会不会通过某种方式获取你的核心算法？这些都不是杞人忧天。特别是对于金融、医疗等敏感行业，数据安全是红线，碰不得。虽然类似于 Cursor 有隐私模式，但这个隐私模式真的隐私吗？或者说这里定义的隐私的边界是什么？

稳定性问题。AI 生成的代码看起来能跑，但真的稳定吗？边界条件考虑了吗？异常处理完善吗？性能优化了吗？很多时候，AI 给出的是「能用」的代码，而不是「好用」的代码。如果团队过度依赖 AI，很可能会埋下大量隐患。

技术债务问题。这是个更深层的问题。当团队习惯了「不求甚解」的开发模式，技术债务会像滚雪球一样越滚越大。代码结构混乱、命名不规范、重复代码满天飞，到最后谁都不敢动，只能推倒重来。

Jim Collins 在《从优秀到卓越》中有句话说得特别好：「轻率地依赖技术是一种债务，而不是资产。」只有当技术服务于清晰的概念和目标时，才能成为推动力。否则，就是加速灭亡的工具。

我的实际使用体验

说实话，这一年多我自己也在大量使用各种 AI 编程工具。从 Cursor 到 Trae(因为 Cursor 不让我用高级模型了)，从 ChatGPT 到 Claude，基本上市面上的工具都试了个遍。体验下来，确实有种「Vibe Coding」的感觉——写代码变快了，做项目没那么费劲了。

但慢下来思考，内心其实有点恐慌。

为什么恐慌？不是工具不好，而是我发现自己在变懒。遇到问题，第一反应不再是分析问题、设计方案，而是想着「怎么让 AI 帮我写出来」。这种思维模式的改变，其实挺可怕的。

以前写一个 API，我会仔细考虑接口设计、参数校验、异常处理、性能优化。现在呢？一句 prompt，AI 啪一下就给你生成了。代码能跑，功能也对，但总觉得哪里不对劲。等你想改的时候才发现，你压根不知道它为什么这么设计，改一个地方，可能会影响十个地方。

还有更可怕的，随着时间的流逝，这种依赖会形成惯性。你用得越多，越像在维护一份「外包」代码。只不过这个外包商是 AI，而你成了那个下需求的产品经理。

表面上看，你在主导 AI。实际上呢？你越来越依赖它，它也越来越多地接手决策。到最后你会发现，代码是它写的，架构是它设计的，你只是个「prompt 工程师」。

这让我想起一个段子：以前是「CV工程师」（复制粘贴），现在升级成「AI工程师」（AI写我调）。看似进步了，其实本质没变，都是不求甚解。

作为 CTO 的思考框架

那么，作为技术负责人，到底该怎么看待和使用 AI 编程工具？我觉得需要建立一个清晰的思考框架。

第一，明确 AI 的定位。AI 编程工具是助手，不是替代品。它应该帮助程序员更高效地实现想法，而不是替程序员思考。这个定位必须在团队内部达成共识，否则很容易走偏。

第二，建立使用边界。什么代码可以用 AI 写，什么不可以？我的建议是：

  • 样板代码、测试用例、文档注释——可以大胆用
  • 业务逻辑、核心算法、安全相关——谨慎用或不用
  • 学习新技术、快速原型——可以用，但要理解原理

第三，强调代码审查。AI 生成的代码必须经过严格的 Code Review。不仅要审查功能正确性，更要审查代码质量、设计合理性、安全隐患等。千万不能因为是 AI 写的就放松标准。

第四，投资团队成长。这点特别重要。AI 工具的普及，对程序员的要求不是降低了，而是提高了。以前你只需要会写代码，现在你需要会判断代码好坏、会设计系统架构、会解决复杂问题。这些能力不是 AI 能替代的，反而因为 AI 的存在变得更加稀缺和重要。

具体的实施建议

如果你决定在团队中引入 AI 编程工具，这里有一些具体的建议：

1. 先试点，后推广

不要一上来就全员推广。选择一两个小团队或项目先行试点，收集使用数据和反馈。试点期至少 3-6 个月，要关注这些指标：

  • 编码效率是否真的提升了？
  • 代码质量有没有下降？
  • 团队成员的接受度如何？
  • 有没有安全或合规问题？

2. 制定明确的使用规范

规范不需要太复杂，但一定要明确。比如：

  • 哪些代码库可以使用 AI 工具
  • 敏感代码和数据的处理原则
  • AI 生成代码的标记和审查流程
  • 工具选型和采购流程

3. 加强技术培训

不是培训怎么用 AI 工具，而是培训如何在 AI 时代保持竞争力。包括：

  • 系统设计能力
  • 代码审查能力
  • 问题分析和解决能力
  • 对 AI 生成代码的判断能力

4. 建立反馈机制

定期收集团队使用 AI 工具的反馈，及时发现和解决问题。可以通过：

  • 月度问卷调查
  • 定期的分享会
  • 1 对 1 沟通
  • 代码质量数据分析

5. 保持技术敏感度

AI 技术发展很快，作为 CTO 要保持对新技术的敏感度。但也不要被各种营销话术忽悠，要基于实际效果做决策。

更深层的思考

站在更高的角度看，AI 编程工具的出现，其实是在重新定义程序员这个职业。

以前，程序员的核心技能是「把想法转化为代码」。现在，这个转化过程很大程度上可以由 AI 完成。那程序员的价值在哪里？

我觉得在于三个方面：

第一，定义正确的问题。爱因斯坦说过，提出问题比解决问题更重要。在 AI 时代，知道要解决什么问题、如何定义问题，变得更加关键。

第二，设计优雅的方案。AI 可以写代码，但很难设计出优雅、可扩展、高性能的系统架构。这需要经验、品味和全局思维。

第三，处理复杂的情况。现实世界的问题往往不是非黑即白的。如何在各种约束条件下找到最优解，如何处理各种边界情况和异常，这些都需要人的判断。

从这个角度看，AI 编程工具不是程序员的终结者，而是一次职业升级的机会。那些只会写代码的程序员可能会被淘汰，但那些会思考、会设计、会解决复杂问题的程序员，会变得更有价值。

对团队文化的影响

引入 AI 编程工具，不仅仅是技术决策，也会深刻影响团队文化。

学习文化的改变。以前遇到不会的，查文档、看源码、问同事。现在呢？直接问 AI。这种便利性是好事，但也可能导致浅尝辄止，不求甚解。作为 CTO，要引导团队保持深度学习的习惯。

协作模式的改变。当每个人都有 AI 助手时，pair programming 还有必要吗？code review 的重点是什么？这些都需要重新思考和定义。

价值认同的改变。什么样的程序员是优秀的？是 prompt 写得好的，还是系统设计得好的？团队的价值导向必须明确，否则容易迷失方向。

风险管理

作为 CTO，风险管理始终是重要职责。在 AI 编程工具的使用上，需要特别关注这些风险：

知识产权风险。AI 生成的代码可能包含其他项目的代码片段，存在版权风险。团队需要有意识地审查和规避。

依赖风险。如果团队过度依赖某个 AI 工具，一旦工具不可用或政策变化，可能会严重影响开发进度。

能力退化风险。这是最隐蔽也最危险的。当团队习惯了 AI 代劳，自主解决问题的能力可能会逐渐退化。等到真正需要的时候，才发现已经力不从心。

安全合规风险。特别是在金融、医疗、政府等行业，数据安全和合规要求很高。使用 AI 工具可能会触碰红线，需要特别谨慎。

一些实用的建议

最后，给正在纠结是否引入 AI 编程工具的 CTO 们一些实用建议：

1. 自己先用起来。不要只看网上别人的视频或他人分享的文章，自己深度使用至少一个月，持续的跟进更新，形成自己的判断和手感。

2. 小步快跑。不要想着一步到位，先从风险较小的场景开始，比如单元测试、文档生成等。

3. 数据说话。建立量化指标，用数据来评估效果，而不是凭感觉。

4. 保持开放。技术在快速发展，保持学习和调整的心态。今天的最佳实践，可能明天就过时了。

5. 关注人。技术只是工具，人才是核心。如何让团队在 AI 时代保持成长和价值，这是最重要的课题。

写在最后

作为 CTO，我们已经站在技术变革的前沿。AI 编程工具的出现，既是机遇，也是挑战。

机遇在于，它确实能提升效率，降低门槛，让我们能够更快地实现想法。挑战在于，如何在使用工具的同时，不失去核心竞争力，不积累技术债务，不触碰安全红线。

这需要智慧，需要平衡，更需要不断的思考和调整。

如果你已经在使用 AI 编程工具，不妨问问自己和团队：

  • 我们是在利用 AI，还是在依赖 AI？
  • 团队的核心能力是在增强，还是在弱化？
  • 面对没有 AI 的场景，我们还能高效工作吗？

如果你还在观望，也不妨思考：

  • 竞争对手都在用 AI 提效，我们不用会不会落后？
  • 如何在保证安全的前提下，适度引入 AI 工具？
  • 团队对 AI 工具的态度如何，有没有抵触或过度期待？

无论如何，保持清醒的头脑，做出适合自己团队的选择。

以 Jim Collins 在《从优秀到卓越》中话结尾：

轻率地依赖技术是一种债务，而不是资产。是的，只有合理地使用技术，让这种技术服务于一个简单、清晰、连贯并且已经被深刻理解的概念时，技术才会成为加速发展的根本推动力。相反，当技术没有被合理使用，只是被当作一个简单的解决办法，也没有被深刻地认识到它是如何与一个清晰连贯的概念联系在一起的时候，技术就是加速你灭亡的工具。

关于 AI Agent： 从 Manus 聊起

最近几天 Manus 的新闻不停的出现在我的信息流中，从 Manus 官方账号清空了微博、小红书上的所有内容，到裁员争议，据说将核心技术人员迁往了新加坡。一个从北京、武汉出发的纯正中国公司，最终选择了离开。

还记得今年火热的 3 月，Manus 发布当天就引爆了社交网络。邀请码一码难求，甚至在二手平台被炒出天价。创始人肖弘（人称red）带领的这支年轻团队，用一个产品点燃了整个行业对 AI Agent 的热情。

2025 年是 AI Agent 元年。AI Agent 的发展速度惊人。不只是 Manus 这种通用型 Agent，还有各种垂直领域的，如 设计领域的 lovart，编程领域的 Claude Code Cursor 等等。

那什么是 AI Agent，它由什么组成？今天我们聊一聊。

1. 从专家系统说起

要说 AI Agent 的历史，得从上世纪 60 年代说起。那时候，计算机科学家们就在琢磨一个事：能不能让机器像人一样，自己去感知环境、做出决策、然后采取行动？

最早的尝试是专家系统。比如 1970 年代斯坦福大学开发的 MYCIN，这是一个诊断血液感染疾病的系统。它的工作方式很简单：问医生一堆问题，然后根据预设的规则给出诊断建议。虽然现在看来很原始，但在当时，这已经算是「智能」了。

到了 80 年代，出现了更复杂的系统，比如 R1/XCON，帮助 DEC 公司配置计算机系统。这些系统有个共同特点：它们都是基于规则的。你得事先把所有可能的情况都想到，然后写成 if-then 规则。问题是，现实世界太复杂了，你不可能把所有情况都考虑进去。

90 年代，研究者们开始尝试新的路子。他们发现，与其让人去编写所有规则，不如让机器自己去学习。于是有了基于机器学习的 Agent，比如强化学习 Agent。这些 Agent 可以通过试错来学习如何完成任务。

但真正的转折点出现在 2010 年代深度学习兴起之后。特别是 2017 年 Transformer 架构的出现，彻底改变了游戏规则。有了 GPT、BERT 这些大语言模型，AI Agent 突然变得「聪明」了很多。它们不再需要人类事先编写规则，而是可以理解自然语言，根据上下文做出合理的判断。

2. 现代 AI Agent 的样子

要理解现代的 AI Agent，我们得先搞清楚它到底是什么。

简单来说，AI Agent 就是一个能够自主感知环境、制定计划、采取行动来完成特定目标的系统。听起来很抽象？我举个例子：

假设你要让 AI 帮你订一张从北京到上海的机票。一个简单的聊天机器人可能只会回答：”请您登录航空公司网站自行预订。”但一个真正的 AI Agent 会这样做：

  1. 理解你的需求（什么时间、预算多少、有什么偏好）
  2. 搜索多个航空公司的航班信息
  3. 比较价格和时间
  4. 根据你的偏好筛选
  5. 甚至可能帮你完成预订（如果有相应的接口）

这就是 AI Agent 和普通 AI 应用的区别：它不是被动地回答问题，而是主动地解决问题。

3. 核心技术和架构

现在咱们来看看 AI Agent 是怎么实现的。核心架构可以分成四个部分：

3.1 感知模块

这是 Agent 的「眼睛」和「耳朵」。它需要理解用户的输入，同时还要感知环境的状态。比如，当你让 AI Agent 帮你写代码时，它需要理解：

  • 你想要实现什么功能
  • 使用什么编程语言
  • 有什么特殊要求
  • 当前的代码结构是什么样的

但这里有个关键点：感知模块需要区分两种不同的信息——状态上下文和意图上下文。

状态上下文是环境的客观信息。比如：

  • 当前项目使用的是 Python 3.9
  • 代码库里已经有了用户认证模块
  • 数据库是 MySQL
  • 使用的是的 FastAPI 框架

这些信息是确定的、可验证的事实。Agent 需要准确地获取和理解这些信息，因为任何误判都可能导致后续行动的失败。

意图上下文则是用户想要达成的目标，这往往更加模糊和主观。比如用户说「帮我优化一下这段代码」，Agent 需要理解：

  • 「优化」是指性能优化还是可读性优化？
  • 用户的性能预期是什么？
  • 有没有特定的约束条件？

区分这两种上下文至关重要。很多 AI Agent 的失败，就是因为混淆了状态和意图。比如，用户说「这个函数太慢了」，Agent 需要识别出：

  • 状态：函数执行时间是 500ms
  • 意图：用户希望降低到 100ms 以内

现代的 AI Agent 通过多种方式来增强感知能力：

多模态感知：不只是文字，还包括图像、语音、甚至视频。Cursor 支持图片上传，代码索引，文档等。

主动询问：当信息不充分时，优秀的 Agent 会主动提问。「你提到要优化性能，具体是想优化响应时间还是内存占用？」这种澄清式的对话，能大大提高后续行动的准确性。

历史记录：通过分析用户的历史行为，Agent 可以更好地理解当前的意图。如果用户之前多次要求「简洁的代码」，那么在新的任务中，Agent 就会倾向于生成更简洁的解决方案。

环境探测：高级的 Agent 还会主动探测环境。比如，在开始写代码前，它可能会先检查项目的配置文件、依赖列表、测试用例等，构建一个完整的环境画像。

感知的准确性直接决定了 Agent 的表现。一个看不清路的司机，再好的驾驶技术也没用。同样，一个不能准确理解用户意图和环境状态的 Agent，后续的规划和执行必然会出问题。

3.2 推理模块

这是 Agent 的「大脑」，也就是大语言模型。现在主流的做法是使用 GPT-4、Claude、Gemini 这样的大模型。但光有大模型还不够，还需要深入理解不同模型的特性，才能让它们更好地工作。

模型的性格差异

就像人有不同的性格，AI 模型也有各自的「个性」。这不是玄学，而是训练方式和优化目标的差异造成的。

以 Cursor 编辑器的实践为例，他们把模型分为两大类：

思考型模型（Thinking Models）：

  • Claude 3 Opus：喜欢先理解全局，会主动推断你的意图
  • Gemini 2.0 Flash：自信果断，经常会做出超出预期的大改动
  • o1：专门为复杂推理设计，会花时间深入分析问题

这类模型就像经验丰富的专家，你给它一个大方向，它会自己规划路径。适合探索性任务、大规模重构、或者当你自己也不太确定最终方案时使用。

执行型模型（Non-thinking Models）：

  • Claude 3.5 Sonnet：等待明确指令，不会过度推断
  • GPT-4 Turbo：行为可预测，适合精确控制
  • 文心一言 4.0：在中文任务上表现稳定

这类模型像是可靠的助手，严格按照你的要求执行。适合明确的任务、需要精确控制的场景、或者当你已经知道要做什么时使用。

选择模型的艺术

选择合适的模型，就像选择合适的工具。你不会用大锤子去拧螺丝，也不会用螺丝刀去砸钉子。

根据任务类型选择：

  • 代码生成：Claude 3.5 Sonnet 和 GPT-4 都很优秀
  • 代码理解和重构：Gemini 2.0 Flash 的长上下文能力突出
  • 复杂 Bug 调试：o1 的深度推理能力更适合
  • 中文文档处理：通义千问、豆包有本土优势

根据交互风格选择：

  • 如果你喜欢给出详细指令：选择执行型模型
  • 如果你偏好给出大方向：选择思考型模型
  • 如果你需要创造性方案：选择更”活跃”的模型
  • 如果你需要稳定输出：选择更”保守”的模型

提示词工程的进化

早期的 AI Agent 严重依赖精心设计的提示词。但随着模型能力的提升，这种情况正在改变。

从复杂到简单： 过去我们可能需要这样的提示词：

你是一个专业的Python开发者。请严格遵循PEP8规范。
在编写代码时，请考虑以下几点：
1. 代码的可读性
2. 性能优化
3. 错误处理
...（还有20条）

现在，一句简单的”帮我优化这段代码”就能得到不错的结果。

动态提示词策略： 现代 AI Agent 会根据上下文动态调整提示词：

  • 初次对话：使用更详细的背景说明
  • 后续对话：只提供增量信息
  • 错误修正：加入具体的约束条件
  • 创造性任务：减少限制，鼓励探索

混合模型策略

越来越多的 AI Agent 开始采用混合模型策略，在一个任务流程中使用多个模型：

  1. 理解阶段：使用 Claude 3 Opus 深入分析需求
  2. 规划阶段：使用 o1 制定详细的执行计划
  3. 执行阶段：使用 GPT-4 Turbo 快速生成代码
  4. 优化阶段：使用专门的代码模型进行微调

这种方式能够充分发挥每个模型的优势，同时控制成本。

3.3 记忆模块

人做事情需要记住前面发生了什么，AI Agent 也一样。记忆分成几种：

  • 短期记忆：当前对话的上下文
  • 长期记忆：之前的对话历史、学到的知识
  • 工作记忆：执行任务过程中的中间状态

但实现一个好的记忆系统，比想象中要复杂得多。

3.3.1 记忆的层次结构

就像人脑有不同类型的记忆，AI Agent 的记忆系统也需要分层设计：

感知记忆（Sensory Memory）：

  • 保存时间：几秒到几分钟
  • 内容：用户刚刚的输入、系统刚刚的输出
  • 用途：处理连续对话中的指代关系

工作记忆（Working Memory）：

  • 保存时间：整个任务周期
  • 内容：当前任务的状态、中间结果、待办事项
  • 用途：复杂任务的分步执行

情景记忆（Episodic Memory）：

  • 保存时间：数天到数月
  • 内容：完整的对话历史、任务执行记录
  • 用途：理解用户偏好、避免重复错误

语义记忆（Semantic Memory）：

  • 保存时间：永久
  • 内容：领域知识、最佳实践、学到的模式
  • 用途：积累经验、提升能力

3.3.2 实现方案-RAG（检索增强生成）

这是目前最成熟的方案。基本思路是：当 AI Agent 需要回答问题时，先去知识库里检索相关信息，然后把这些信息作为上下文提供给大模型。

比如你问：”我们公司的年假政策是什么？”Agent 会先去检索公司的政策文档，找到相关内容，然后基于这些内容生成回答。

RAG 的进化史

第一代 RAG（2020-2022）：

  • 简单的向量检索
  • 使用 BERT 或 Sentence-BERT 做编码
  • 召回 Top-K 相关文档
  • 效果一般，经常找不到真正相关的内容

第二代 RAG（2023-2024）：

  • 引入混合检索（向量+关键词）
  • 使用更强的编码模型（如 BGE、E5）
  • 加入重排序（Reranking）步骤
  • 开始考虑文档结构和语义分块

第三代 RAG（2024-现在）：

  • 多级索引结构（摘要→章节→段落）
  • 查询改写和扩展
  • 动态上下文窗口调整
  • 引入知识图谱增强检索

实践中的 RAG 优化技巧

  1. 智能分块：不要机械地按字数切分，而是按语义单元切分

    • 代码：按函数/类切分
    • 文档：按章节/段落切分
    • 对话：按话轮切分

  2. 多路召回：同时使用多种检索策略

    • 向量相似度检索
    • BM25 关键词检索
    • 实体链接检索
    • 基于图的检索

  3. 上下文工程：检索到的内容需要精心组织

  4. 增量索引：新知识的实时更新

    • 使用流式处理架构
    • 支持热更新索引
    • 版本控制和回滚机制

3.3.3 实现方案-超长上下文

最新的趋势是直接增加模型的上下文长度。比如 Claude 3 已经支持 200K token 的上下文，Gemini 1.5 Pro 甚至支持 200 万 token。

长上下文的真实挑战

虽然模型号称支持超长上下文，但实际使用中会遇到很多问题：

  1. 「迷失在中间」现象：模型对上下文开头和结尾的内容记忆较好，但中间部分容易遗忘

  2. 注意力稀释：上下文越长，模型对每个部分的注意力就越分散

  3. 推理退化：在超长上下文中，模型的推理能力会显著下降

混合方案：长上下文 + 选择性注意

3.3.4 主动遗忘

这是一个反直觉但很重要的概念：不是记住越多越好，而是要学会遗忘。

为什么需要遗忘？

  1. 降噪：不是所有信息都值得记住
  2. 隐私：某些敏感信息需要及时删除
  3. 效率：保持记忆系统的高效运转
  4. 相关性：过时的信息可能产生负面影响

遗忘策略

  1. 基于时间的遗忘：

    • 会话结束后 24 小时删除临时信息
    • 30 天后归档低频访问的记忆
    • 90 天后删除无用的错误记录

  2. 基于重要性的遗忘：

    • 使用 LRU（最近最少使用）策略
    • 基于访问频率的动态评分
    • 保留高价值的”关键时刻”

  3. 基于相关性的遗忘：

    • 当新信息与旧信息冲突时，更新而非累加
    • 合并相似的记忆，避免冗余
    • 定期整理和压缩记忆库

3.4 行动模块

这是 Agent 的「手脚」，让它能够真正做事情。

行动模块的核心是 Function Calling（函数调用），这是目前最主流的方式。

简单来说，就是预先定义好一系列函数，比如搜索网页、查询数据库、发送邮件等，然后告诉大模型这些函数的作用和参数。

当用户提出需求时，模型会判断需要调用哪个函数，提取相应的参数，执行函数并获取结果。这个过程已经从最初的单次调用，进化到现在可以进行多步骤调用、并行执行、错误重试等复杂操作。

Anthropic 推出的 MCP（Model Context Protocol）协议，试图建立行动模块的统一标准。

MCP 采用服务器-客户端架构，工具提供方作为服务器，AI 应用作为客户端，通过标准化的协议进行通信。这种设计的好处是解耦和复用：AI 应用不需要知道工具的具体实现细节，一个 MCP 服务器可以同时服务多个 AI 应用。更重要的是，MCP 提供了统一的安全管理和权限控制机制，让行动模块的集成变得更加简单和安全。

安全性是行动模块最关键的考虑因素。

在 Manus 刚上线的时候就爆出一个问题，有人用提示词，让 AI Agent 打包了当前执行的环境的所有代码。

给 AI 执行能力就像给孩子一把剪刀，必须设置严格的安全边界。现代 Agent 通常采用多层防护：首先是沙箱环境，所有代码执行都在隔离的容器中进行，限制内存、CPU、网络访问；其次是权限管理，基于用户角色和具体场景动态分配权限；最后是审计日志，记录所有行动的执行情况，便于追溯和分析。这些措施确保 Agent 在帮助用户的同时，不会造成安全风险。

复杂任务往往需要多个行动的协调配合，这就需要工作流引擎来编排。比如”帮我分析竞品并生成报告”这个任务，可能需要先搜索竞品信息，然后提取关键数据，接着进行对比分析，最后生成可视化报告。工作流引擎负责管理这些步骤的执行顺序、处理步骤间的数据传递、应对执行失败等情况。高级的引擎还支持条件分支、循环执行、并行处理等复杂逻辑，让 Agent 能够处理更加复杂的任务。

行动模块的未来发展方向是更强的自主性。目前的 Agent 主要执行预定义的动作，但未来可能会具备动作发现和学习能力，能够自动发现新的 API、学习新的操作模式、甚至创造性地组合已有动作来完成新任务。另一个重要方向是与物理世界的交互，通过机器人或 IoT 设备执行物理动作。随着这些能力的提升，AI Agent 将真正从「会说」进化到「会做」，成为人类在数字世界和物理世界中的得力助手。

4. 当前的局限性

AI 有其局限性，了解这些局限性，对于合理使用和未来改进都很重要。

4.1 幻觉问题

这是所有基于大模型的 AI Agent 都面临的核心挑战。

Agent 可能会编造不存在的 API、虚构执行结果、或者对自己的能力过度自信。比如，当你要求 Agent 查询某个数据库时，它可能会返回看起来合理但实际上完全虚构的数据。

这种幻觉在连续多步骤的任务中会被放大，一个小错误可能导致整个任务链的崩溃。

更危险的是，这些幻觉往往很难被发现，因为它们在表面上看起来完全合理。虽然通过 RAG、工具调用验证等方法可以部分缓解，但彻底解决仍然是个开放性难题。

4.2 可靠性不足

AI Agent 的表现稳定性仍然是个大问题。

同样的任务，在不同时间执行可能得到不同的结果。

这种不确定性来源于多个方面：模型本身的随机性、上下文理解的偏差、外部环境的变化等。

在一些对可靠性要求高的场景，比如金融交易、医疗诊断、工业控制等，目前的 AI Agent 还远远达不到要求。

即使加入了重试机制、结果验证等保障措施，也只能提高而非保证可靠性。这导致在关键业务场景中，AI Agent 更多是作为辅助而非主导。

4.3 成本与效率

运行一个功能完善的 AI Agent 系统成本不菲。

首先是模型调用成本，特别是使用 GPT-4、Claude 等顶级模型时，每次交互都要花费不少钱。复杂任务可能需要多次模型调用，成本会快速累加。

其次是延迟问题，每次函数调用、每次推理都需要时间，一个看似简单的任务可能需要等待数十秒甚至几分钟。对于需要实时响应的场景，当前的 AI Agent 往往力不从心。

虽然可以通过模型蒸馏、缓存优化等手段降低成本，但在性能和成本之间找到平衡点仍然很困难。

4.4 安全与隐私挑战

AI Agent 需要访问大量数据和系统才能发挥作用，这带来了严重的安全隐私问题。

首先是数据泄露风险，Agent 可能无意中将敏感信息包含在给大模型的请求中，而这些数据可能被用于模型训练。

其次是提示注入攻击，恶意用户可能通过精心构造的输入操控 Agent 执行非预期的操作。

还有权限滥用问题，一个被赋予过多权限的 Agent 可能造成严重损害。

虽然业界正在开发各种防护措施，如差分隐私、安全沙箱、细粒度权限控制等，但攻防对抗仍在继续。

4.5 理解与推理的局限

虽然大模型展现出了惊人的能力，但 AI Agent 在深层理解和复杂推理方面仍有明显不足。它们往往只能处理相对直接的任务，面对需要长链条推理、创造性思维或深层次理解的问题时就会暴露短板。

比如，Agent 可能很擅长执行”帮我订一张机票”这样的任务，但如果要求”帮我规划一个考虑预算、时间、个人兴趣的完整旅行方案”，效果就会大打折扣。

此外，Agent 缺乏真正的常识推理能力，可能会提出一些违背基本常识的方案。即使是最新的 o1 模型，虽然推理能力有所提升，但距离人类水平的推理能力还有很大差距。

5. 写在最后

AI Agent 的发展才刚刚开始。虽然现在的技术还不完美，但进步的速度是惊人的。两年前，我们还在惊叹 ChatGPT 能够进行对话；现在，AI Agent 已经能够帮我们写代码、分析数据、制定计划了。

对于技术人员来说，现在是最好的时代。我们有机会参与到这场变革中，创造出真正有用的 AI Agent。但同时，我们也要保持清醒：AI Agent 是工具，不是魔法。它能够提高效率，但不能替代人类的创造力和判断力。

未来的世界，可能每个人都会有自己的 AI Agent 团队。就像现在每个人都有智能手机一样自然。

而现在，正是这个未来的开端。

以上。