2025 年总结：从 Copilot 到可执行 Agent

如果说早期的 AI 编程工具像一个坐在旁边的助手，那么 2025 年的 Agent 更像一个拿到任务以后会自己拆步骤、查资料、调用工具并交付结果的实习工程师。

这听起来只是“会做更多事情”，实际上是一次很大的变化。Copilot 主要负责补全和建议，错了通常是一段代码不对；可执行 Agent 会修改文件、运行命令、访问系统，错了就可能造成真实副作用。模型能力往前走了一步，工程责任也跟着往前走了一大步。

我回顾这一年的学习和实践，最大的感受不是某个模型又刷新了榜单，而是我们终于不得不认真回答几个问题：谁允许 Agent 做这件事？它现在处于哪一步？工具调用是否成功？任务中断后能否恢复？它给出的结果怎么证明？

一、Copilot 解决的是“帮我写”，Agent 面对的是“帮我做”

代码补全的交互通常很短：用户输入几行上下文，模型给出建议，人来接受或拒绝。Agent 的任务则更长：

目标：修复一个搜索 Bug
  ↓
读取 Issue 与项目规则
  ↓
定位相关代码和测试
  ↓
制定修改计划
  ↓
生成补丁
  ↓
运行测试并分析失败
  ↓
整理 Pull Request

每一步都可能需要工具和状态。模型不只是生成文字，还要决定下一步做什么，并根据工具返回重新规划。于是 Agent 的质量不再由某一段代码是否漂亮决定，而由整个任务是否最终完成、有没有越界和能不能解释决定。

二、工具调用是能力，也是风险入口

Tool Calling 让模型可以使用搜索、数据库、浏览器、代码执行器和业务 API。一个工具定义应该包含清楚的参数和权限：

type ToolDefinition = {
  name: string
  description: string
  inputSchema: unknown
  risk: 'low' | 'medium' | 'high'
  allowedRoles: string[]
  idempotent: boolean
}

模型可以选择调用工具，但不能因此获得无限权限。服务端必须重新校验租户、用户、资源和参数，不能因为参数是模型生成的就跳过授权。

搜索资料和读取代码通常是低风险动作；发送邮件、删除文件、修改权限、付款和发布内容则是高风险动作。高风险动作应拆成预览和确认两步，让用户看到对象、参数和影响范围，再决定是否提交。

三、推理模型让“先想清楚再行动”变得可用

复杂任务需要规划和校验。模型可以先拆任务，再执行子步骤，最后检查结果。这个过程不是越长越好，关键是每一步都产生可验证的中间状态：

计划：读取 20 个文件
实际：成功读取 18 个，2 个权限不足
判断：不能假设全部读取成功
下一步：请求用户授权或明确说明缺失范围

如果模型只是输出一段很长的思考，却没有结构化状态和工具结果，系统依然无法知道它做了什么。推理的价值要通过计划、动作、观察和校验体现出来，而不是通过文字长度体现。

四、Agent 需要记忆，但记忆应该由系统保存

短期上下文可以放在当前对话里，长任务则需要持久化：

type AgentState = {
  taskId: string
  goal: string
  completedSteps: string[]
  pendingSteps: string[]
  toolResults: Record<string, unknown>
  checkpointVersion: number
}

不要让模型重新阅读一大段历史来猜已经完成了什么。结构化状态告诉它哪些是事实，模型只负责当前步骤的决策。进程崩溃、页面刷新或网络断开以后，任务仍然可以从检查点恢复。

五、可靠 Agent 必须考虑重复和失败

在分布式系统里，工具执行成功但响应丢失是很常见的情况。如果 Agent 不知道动作是否已经发生，就可能重复发送、重复创建或重复扣款。

每个有副作用的操作都要有幂等键：

const operationId = `${taskId}:${stepId}`
await tool.execute({ operationId, ...payload })

重试也要分类。网络超时可能意味着结果未知，应该先查询；参数错误不应该重复请求；权限错误不能靠重试解决；限流则需要退避。把所有错误都交给模型自行判断，是一种很昂贵的偷懒。

六、MCP 和统一协议带来了新的连接方式

当模型和工具越来越多，大家开始需要统一的连接协议。协议的价值不是让所有工具长得一样，而是让发现能力、描述 Schema、发送调用和返回结果有共同约定。

但统一协议不等于统一信任。每个 Server 仍然要有身份、权限、版本和数据策略；客户端不能因为工具描述写着“安全”就默认允许执行。工具发现和工具授权必须分开，工具能被看见，不代表当前用户可以使用。

七、Agent 评测不能只问“答得像不像”

Agent 的结果要看任务是否完成：

• 工具选择是否正确；
• 参数是否符合 Schema；
• 步骤顺序是否合理；
• 是否重复执行副作用；
• 失败后是否安全停止；
• 最终状态是否达到目标；
• 成本和延迟是否在预算内。

type AgentEval = {
  taskSuccess: boolean
  toolAccuracy: number
  invalidCallCount: number
  duplicateSideEffectCount: number
  recoverySuccess: boolean
  cost: number
  latencyMs: number
}

测试集应该包含正常任务，也要包含工具失败、权限不足、信息缺失、重复消息和用户取消。一个只在顺利路径上表现出色的 Agent，还没有真正准备好进入生产。

八、人机协作不是退步，是安全阀

人类确认并不意味着 Agent 失败。对于不可逆、高风险和用户很难事后修复的动作，保留人工确认是合理设计。Agent 可以把资料找齐、参数填好、影响范围列出来，让人做最后判断。

Agent：准备删除 12 个过期文件，列出清单和来源
用户：确认删除
系统：执行幂等删除并记录审计

确认界面必须说清楚动作对象、参数、风险和取消方式，不能只放一个模糊的“继续”。用户如果不知道自己确认了什么，确认就没有真正的意义。

九、2025 年留下的三个教训

第一，模型越能行动，权限边界越重要。第二，任务越长，状态持久化和检查点越重要。第三，系统越复杂，评测和可观测性越重要。

我们不应该把 Agent 当成“更聪明的聊天框”。它更接近一个由模型驱动的工作流系统，既需要模型的判断，也需要普通软件工程里的状态机、队列、事务、重试、审计和回滚。

总结：从辅助生成到值得托付

2025 年的主线，在我看来不是“AI 会不会替代程序员”，而是我们开始认真讨论：哪些工作可以交给模型，怎样交，交出去以后谁负责验证。

Copilot 让写代码更快，Agent 让完成任务成为可能；工具让模型能够行动，状态和检查点让行动可以持续；权限、幂等、评测和人工确认，则让行动不至于失控。

一个值得托付的 Agent 不会因为自己能调用很多工具就显得强大。它应该知道目标是什么，知道当前做到哪一步，知道哪些动作需要确认，知道失败后怎样恢复，也知道证据不足时应该停下来。

当模型从“帮我写一段”走向“帮我把这件事做完”，真正的进步不是把人的判断拿掉，而是把重复劳动交给机器，把边界和最终责任保留在人手里。这大概就是 2025 年最重要的工程答案。