这几年做 Agent 相关项目我最大的一个感受是控制权正在变。以前我们习惯把逻辑写在代码里——状态机、节点、边、YAML 编排文件模型只是中间一个会说话的 API。但最近半年我越来越明确地感觉到决定一个 Agent 能干多少活的已经不再是外部框架有多完善而是模型本身有多强、多稳、多用得住。Claude Code、Codex 这类产品几乎是在明晃晃地证明一件事给模型足够的上下文、正确的边界、必要的工具它自己就能把任务跑完根本不需要你在外面套一堆 if-else。这不是某一家公司的产品设计偏好而是整个技术路线在换方向。控制权从框架手里往模型手里迁移背后是模型能力、上下文长度、工具协议、评估方式等一系列基础设施发生了质变。如果你还在用两三年前那套工作流编排为主、模型填空为辅的思路做 Agent你很快就会遇到瓶颈。这篇文章我尽量不端着讲理论就顺着我自己的项目实践聊聊这个转移到底是怎么发生的、它为什么必然发生以及我们这些做应用的开发者接下来该把力气花在哪。1. 先看一个反直觉的现象控制权在往模型手里走1.1 三年前的项目长什么样2023 年我做过一个客服 Agent当时的架构在今天看会觉得特别笨重一个对话管理模块一个意图识别模块一个槽位填充模块外加一个写死的工作流引擎。用户说我要改地址系统必须先跑意图分类再抽地址实体然后查订单状态最后在流程图上走到改地址这个节点调后端的改地址接口。整个链路的控制权百分之百在代码和配置里模型只负责填空——分类标签、实体列表仅此而已。那套方案的优点是可预测每条路径都走得到也能测缺点是改业务逻辑要改代码新场景上线要画新流程图稍微边界一点的用户表达就掉进兜底分支。后期维护成本高得吓人因为状态多了之后状态机就会长出各种各样你根本没设计过的路径。到 2024 年我帮一个客户做内部知识库问答 Agent架构变了但思路没变检索、重排、组装 prompt、调模型、格式化输出每一步都是程序控制的。模型依然是一个被框在流程里的组件只是填充的内容从实体变成了答案。1.2 现在大家默认的做法变了到了 2025 年情况完全不一样了。用 Claude Code 的过程让我印象很深你根本不会去设计什么工作流、节点、边你只需要给它一份说明文档告诉它项目背景、常用命令、代码规范然后直接提需求。它自己决定先看哪个文件先跑哪个命令要不要写测试遇到报错怎么排查。整个工作流是模型在脑子里按需即兴生成的不是预先把图给画好的。这不是我一个人的感觉。去翻一下现在主流的 Agent 产品几乎都在往模型主导环境约束这个方向收敛Claude Code 的 hooks、subagents、CLAUDE.md 指令文件OpenAI Codex 的自然语言任务描述Cursor 的 AGENTS.md 项目规则。大家不约而同地把越来越多的主动权交给模型把工程重心从写代码编排模型转移到配置环境引导模型。这里面有个术语值得说一下harness 和 agent 的区别。过去我们习惯把模型外面包的那层东西叫 harness负责调度、记忆、工具调用模型只是被 harness 提着走的执行器。现在这个边界变模糊了——harness 做的是把环境准备好把工具暴露好把规则说清楚然后让模型自己在里面跑。与其说模型被困在 harness 里不如说 harness 变成了模型的外设。2. 为什么控制权最初会被框架收走这是一段必然经历2.1 模型能力不够只能用外部逻辑兜底回头看 2022、2023 年那批 Agent 项目控制权之所以全在框架手里最根本的原因是模型能力扛不住端到端的自主规划。当时的主流模型上下文窗口基本在 4K 到 16K 之间你让它一次看完十个文件、记住前后二十轮对话它是真的会失忆。推理能力也有限让它做复杂的多步规划它经常走着走着就迷路了。工具调用更是要靠微调或者强 prompt 才能勉强稳定输出。在这种条件下你要是敢把控制权交给模型让用户一句帮我完成这次报销就放手让它自己去查邮件、填表单、走审批结果是灾难性的——它会在第三步就忘掉第一步的目标。所以大家只能把任务拆细一个节点做一件小事把上下文隔离开让每个模型调用都处在一个足够简单的状态。框架控制其实是在给模型的短板擦屁股是一种必要的工程补偿不是谁的设计品味有问题。2.2 框架控制付出的真实代价框架控制可不是没有成本的而且成本越到后期越明显。我踩过的坑可以归成三类。第一类是状态爆炸。你为了让 Agent 记得现在在哪个环节不得不在代码里维护一个状态对象这个对象会随着业务复杂度膨胀到不可维护。原本画流程图的时候很爽跑起来之后各种隐藏路径层出不穷你会花大量时间处理用户在第 3 步反悔了怎么办工具报错了要回退到第几步这类分支。第二类是流程僵化。框架是预先写死的模型的灵活性一点没发挥出来。用户换了一种说法、任务绕了一条新路径流程就断了兜底逻辑只能让用户换个方式重试。明明是 AI 产品体验比传统软件还死板。第三类是调试地狱。本来指望框架让系统更可控结果状态、上下文、每一步的输入输出层层嵌套出了问题你根本不知道是模型答错了、工具调用错了、状态更新错了还是 prompt 写错了。查一个 bug 的时间够你重写半个模块。所以那两年做 Agent 的痛苦不是个例Agent 上线容易做好太难基本是行业共识。现在回头看问题不在 Agent 这个概念有问题而是我们把控制权放错了位置——放在了一个不擅长处理开放场景的代码层而不是放在一个擅长理解任务和生成路径的模型层。3. 模型凭什么能拿回控制权几个关键能力已经到位3.1 上下文变长、推理变强模型接得住整条任务链控制权交还的第一前提是模型得接得住。现在的旗舰模型上下文窗口动辄 100K、200K配合上下文压缩和记忆机制Agent 可以连续工作几小时而不丢失关键信息。这意味着以前靠代码拆解的任务隔离现在模型自己在上下文里就能完成它把目标记住把已经做完的步骤记住把待办清单记在脑子里不需要外部状态机帮它记账。推理能力的提升同样关键。推理模型和长思维链让模型在行动之前会想一会儿这个想一会儿在 Agent 场景里价值极高。你在 prompt 里只写了目标帮我把这周的新需求整理成开发任务并发给对应负责人模型自己会在内部模拟一遍先看需求文档、拆任务、对应负责人、起草消息、调用通讯工具发送。这种在行动前规划、在行动中反思、在遇到问题时调整路径的能力恰好就是以前框架控制想实现但因为太死板而实现不好的东西。3.2 工具调用的主动权从程序决定变成模型决定以前的工具调用链路是我见过最啰嗦的代码之一模型输出一个 JSON程序解析它、校验参数、分发到对应的函数、拿到结果再拼回上下文。每一步都是程序在决定该不该调工具调哪个工具参数怎么补全。模型只是被动地输出那个 JSON没有任何自主权。现在主流的产品里工具调用已经是模型的能力之一。模型可以在思考过程中主动提出我需要查一下这个仓库的依赖版本我需要跑一下测试看看有没有问题我需要翻一下这个接口的文档然后自己发起调用、读取结果、判断是否还需要再调。这个变化看起来小但体验差异是天壤之别。以前 Agent 只能按固定脚本调工具现在 Agent 是在动态决定什么时候该调工具、调完怎么用结果。主动权和判断权从代码转移到了模型。3.3 同一个模型可以按需变形可塑性带来新的控制方式还有一个容易被忽视的点现在的模型在角色塑造上的可塑性极强。以前你想让一个模型扮演不同的角色得微调、得训练 lora耗时耗力。现在你只需要在系统提示词里写清楚角色、目标、风格、边界模型就能按要求切换。这带来一个很有意思的工程变化我们不再需要为每个场景训练一个模型只需要为每个场景写一份好的角色说明书。Claude Code 里的 CLAUDE.md、Cursor 里的 AGENTS.md就是这种角色说明书的文件化。你把项目背景、代码风格、关键路径、禁忌事项写清楚模型打开项目时会自动读取然后以你期望的方式工作。更妙的是这个角色还可以由模型自己扩展——比如 Claude Code 的 subagent可以让主 Agent 按需生成一个临时的子 Agent 去执行专门任务。角色不再由代码固定而是由模型动态生成。这种软控制替代硬控制是控制权转移最核心的体现。4. 控制权回落后工程重心转移到哪里去了4.1 从写流程到写说明书环境设计取代流程编排说实话控制权交给模型以后工程并没有变得没事干反而更考验设计能力了只是设计对象变了。以前设计的是流程图、状态机、分支逻辑现在设计的是 prompt、指令文件、工具协议、权限边界。我把它叫环境设计——你决定不了模型每一步怎么做但你可以决定它在什么环境里做、有什么工具可用、有什么规则必须遵守。操作上我会建议每个 Agent 项目都配一份权威指令文件比如项目根目录下的 AGENTS.md。里面至少写清楚这几部分项目背景与核心目标、命令与脚本的使用方式、关键目录结构说明、常见任务的标准流程、必须遵守的纪律比如不允许直接修改生产配置所有代码变更必须附带测试说明。这份文件就是模型的宪法它做事之前会先读它。实测下来一份写得好的指令文件能显著降低模型跑偏的概率。同时工具的暴露方式也要重新设计。以前我们习惯把工具封装成 API写一大堆文档让模型猜怎么用更好的做法是像 MCP 那样把工具做成模型原生可读的协议带清晰的描述、参数 schema、错误码。模型用工具的方式越接近它理解的自然语言它的自主规划就越顺。所以 MCP 这类协议的意义不只是标准化了工具接口更是在模型和现实世界之间搭了一个低摩擦的操作面。4.2 记忆、评估、安全成为新的控制点流程被模型接管之后工程师真正要花心思的是三个新控制点。第一个是记忆。模型上下文再长也是有限的而 Agent 要面对的对话和任务会持续很久。给模型配一套记忆机制是必须的短期记忆靠上下文长期记忆靠向量库、结构化存储或者文件。我们在项目里会让 Agent 在关键节点主动总结并把结论写进一个 MEMORY.md 文件下次启动时读回来。这比外部 RAG 接入更简单而且模型自己维护的记忆贴合度反而更高。当然要注意记忆污染问题不是所有信息都值得长期记写记忆文件时要有标准比如只记录跨会话仍有效的事实不记录临时状态。第二个是评估。模型自主规划带来的风险是输出不可预知你不能像测流程图那样穷举路径。所以 Agent 项目的评估体系必须配套升级小到单步输出正确率大到整个任务链路的完成率、耗时、返工率都要有指标可观测。我们在团队里搭了一套 agent evals 流程把历史真实用户问题做成评测集每次修改 prompt、升级模型、调整工具之后都跑一遍回归看完成率抖动。没有评估兜底你根本不敢让模型自主控制因为你不知道它这次会走哪条路。第三个是安全。控制权交给模型意味着你在把生产系统的部分操作权交给一个生成式系统必须有边界。工具层要做权限最小化给 Agent 的工具权限要比人工操作更低比如能读的库不要给写权限能测试的环境不要给生产权限模型层要做约束在 prompt 里明确遇到权限不足时停下来请求确认不要尝试绕过限制。安全不是限制模型的能力而是定义模型能触碰的边界。边界清晰模型反而更敢在边界内发挥。4.3 对开发者技能树的冲击从写逻辑到写引导这个变化对开发者个人的冲击也很直接。过去做 Agent 核心技能是写调度代码、写状态机、调工具链你本质上是一个流程工程师。现在这些工作在被模型逐步替代真正值钱的能力变成了三种。第一种是任务拆解与描述能力。你能不能把一个模糊的业务目标拆成模型能理解、能执行、能验证的任务序列这比写代码难因为它要求你同时懂业务、懂模型、懂工具边界。第二种是上下文工程能力。你知不知道什么信息该给模型、什么信息不该给、以什么格式给最省 token 又最有效第三种是评估与迭代能力。你搭建的评测集够不够贴近真实场景你敢不敢在评测通过之后把它放给真实用户用。这三样能力才是模型主导式 Agent时代真正稀缺的。很多还在用老思路的团队转型期的痛苦我见过不少。他们习惯了写流程一上来就问这个 Agent 的流程图怎么画其实他们应该问这个 Agent 的指令文件怎么写、评测集怎么搭、工具怎么暴露。思维转不过来控制权转移的技术红利就跟你没关系。5. 我的实操观察与踩坑记录5.1 团队迁移到模型主导工作流后的真实数据今年年初我们把自己内部的一个文档处理 Agent 从流程编排式重构成了模型主导式。前后对比的体验挺说明问题。老版本8 个状态节点、14 个工具调用点、一堆 if-else 处理边界情况一个月迭代一次新需求测试用例上千条但还是经常在用户一句话多说几个弯之后掉链子。新版本砍掉了状态机留下一个主 Agent 三个 subagent一个处理文档解析一个处理信息抽取一个处理生成输出。指令文件写了两千多字工具从 14 个收敛到 6 个。效果是单任务完成率从 87% 提升到 96%平均处理时间从 3 分半缩短到 1 分 20 秒新增需求的迭代周期从一个月缩到两三天。最让我意外的是用户反馈的机器味明显变轻了因为模型自己判断节奏不再被流程卡出机械回复。5.2 三个仍然踩过的坑迁移过程不是一帆风顺有几个坑要说一下。第一个坑是过度信任模型的自主规划。刚开始我们给了 Agent 很大的自由结果它在一步操作失败后自己发明了一个绕行的方案绕得还挺聪明但绕完之后结果错了。后来我们加了一条规则重要步骤必须走完验证再继续失败超过两次必须停下来报告模型的自主性没丢但多了一个安全阀。第二个坑是上下文被垃圾占满。收益于长上下文我们把很多文件一次性塞进去结果模型在小事上纠结把有限的上下文预算花完了正事反而没做好。解决方式是一场做减法能检索的不预载能按需读的不提前读。上下文管理在模型主导时代反而更重要了只是它的职责从程序控制变成了模型设计共同控制。第三个坑是评测集没有覆盖长尾需求。我们的评测集一开始主要收集高频问题模型在这些问题上表现相当好一上真实用户就漏出各种闻所未闻的场景。后来把评测集扩充到包含大量边缘案例和异常输入模型的真实表现才被压出来。做 agent evals样本的代表性比数量重要得多。5.3 给正在转型的开发者的实操建议如果你现在正要开始做 Agent 项目或者正在重构手上的老 Agent我建议你按这个顺序来做第一步先把任务想明白。不要急着写代码先把业务目标拆成一个主 Agent 能理解的任务描述想清楚哪些子任务需要独立模型、哪些用子 Agent、哪些直接用工具。第二步把环境搭好。写一份覆盖项目背景、命令、规范、禁忌的 AGENTS.md 类指令文件把工具按 MCP 风格包装好暴露最小够用的权限。第三步搭评测集再开发。先收集过往真实问题和预期结果做一个能自动跑的回归评测再开始调 prompt、调模型。第四步小步上线迭代。先放给少量用户盯日志、盯完成率边跑边改指令文件和工具。这套流程下来你会发现 Agent 项目的核心工作不再是写代码而是设计模型的工作环境和评估模型的工作质量。刚开始会有一种失去掌控的不适应但实际上你得到的是一种更高级的掌控——你不再管每一步怎么走但你可以决定它往哪个方向走、能走多远、走到什么程度算合格。这种掌控感恰恰是流程编排时代给不了的。我个人最近的体会是Agent 这场变革的核心不是某个框架、某个模型、某个工具的胜利而是控制思路的胜利。我们把控制权从代码手里还给了模型不是因为代码不好而是因为模型已经长到了能接住这份权力的阶段。接下来谁会做得更好就看谁更快适应写说明书、搭环境、做评估这套新玩法了。