智能代理

在每个使用编程智能助手的开发者生命中，总有一个时刻，你盯着月结账单看，心想：“这些服务确实很好用，可我的订阅怎么比小区健身房的会员费还多？” 那个时刻就这样悄然降临了。当时我同时订阅了Claude Max 5、Codex Plus，还在考虑加上Z.AI配合OpenCode处理廉价的机械性工作。理论看上去很美好。问题出在这样搞下去，就像一个管理乱糟糟工地的包工头，工人各忙各的，却没人看图纸。 我的初步想法很简单：在自动化分流之前，最好先手动做个小实验，持续两周。规则简单，但明确。 问题不在于成本，而在于协调 分开来看，支付23欧元、90欧元或者10美元一点也不算多。 问题在于，当每个工具开始互相干扰时，就开始麻烦了。你让一个助手思考，另一个实现，再让第一个检查，最后还要麻烦第三个处理一些琐事。二十分钟后，你已经搞不清楚是在优化成本、提升质量，还是单纯地折腾自己不停切换窗口了。 用大白话说：真正的成本不仅仅是订阅费，还有你的上下文切换成本。 就像一个厨房里同时有一把日本刀、一台智能厨师机、和一个空气炸锅。它们各有用处，各有千秋。但如果你用厨师机来炸土豆，那肯定不行。 假设：思考、执行、清理 我想要试验的规则说起来不过三句话： 用Claude进行思考 用Codex完成主要实现 用GLM/Z.AI处理基础任务 这不是学术讨论，而是一条实用的工作坊规则。 当一项任务模糊不清、涉及架构、存在风险或者需要判断时，把它交给擅长推理的代理是最合逻辑的选择。在这个实验中，就是Claude。 而当一项任务已经很明确，需要进入代码库、修改文件、运行测试并在错误间反复调试时，就轮到Codex登场。 至于那些没有人愿意干但必须有人去完成的工作，比如简单的测试代码、文档编写、小脚本处理、文件重命名或机械化的代码重构，那么就让GLM+OpenCode来试试。 暂不考虑的事情 目前还不考虑设置一个自动化分流器。 我不打算弄一个能自动读取提示词、分类任务、选择代理、按时间切换模型，还能输出漂亮图表证明其复杂性的魔法中介层。 这听起来或许是个超级有趣的项目，但也可能事倍功半。 这里最常见的错误是在真正需要航管之前就急着建塔台。先观察好了，再决定是否需要设置交通信号灯。 手动操作的两周实验 我的实验相当朴实，够不上“炫技”，但大概率更有用。 1. 用Claude处理复杂任务 当以下情况之一发生时，我会优先用Claude： 我不确定怎么入手 需要设计决策 存在破坏性风险 需要审查逻辑或论证，而不仅仅是代码 翻译成人话：如果任务需要准确判断，我不会吝啬。 2. 用Codex主导代码库工作 当任务已经清晰时，我会用Codex处理： 实现真实的功能修改 修复测试 带验证的重构 反复迭代，直到项目重新回到稳定状态 在这个阶段，一个好的执行代理最能展现价值。这不是模型本身的问题，而是流程的问题。 3. 用Z.AI负责简单工作 对于Z.AI，规则很简单： 模板代码 初稿 文档 简单的测试 小型脚本 文件重命名 容易检查的机械性操作 即使失败了，也没关系。可以随时丢弃，然后换成别的工具重做。 这才是关键。我不会向GLM要求飞针走线般的精细活，我的目标只是拧几颗螺丝。 最重要的规则：失败两次便升级 这一点是最重要的，但也最容易被忽视。 当一个便宜的工具失败了，你可能会倾向于继续试，“再试一次就好”，“这次应该可以”，“我改下提示词试试”，“再加点上下文”。半个小时过去了，你还在像与“抓狂的打印机”讨价还价一样调整模型。 我的规则是： 如果Z.AI1到2次尝试后仍失败，那我就提升它 如果是执行问题，转交Codex 如果是理解或设计问题，转给Claude 低成本工具一旦浪费掉太多时间，就不再低成本。 我要真正关注的是什么 我对“表演式性能对比”没兴趣。 不会去费劲列出诸如每秒处理字节数、平均延迟这类看起来“很专业”的表格，毕竟我的主要问题还是怎么快速重命名40个符号，而不是花一下午来折腾。 但我要在这两周内统计以下内容： 指标 意义 Z.AI吸收的简单任务数量 它是不是真的帮我减少负担 我有多少次需要提升任务 节省的时间和金钱是否值得 减少的Codex使用量 整体思路是否划算 切换工具的总耗时和难度 系统是否够流畅，易于长期使用 如果实验成功，那再好不过。 ...

TL;DR: 在165次Claude Code会话和27次Codex CLI会话后，我发现了一个清晰的模式：早上使用Claude来处理需要头脑风暴的互动型任务，下午让Codex完成可自动执行的具体任务。这不是哪个更好的问题，而是何时使用哪一个的问题。数据显示，两者结合远胜于单独使用任何一个。 早上九点，手握一杯咖啡，我脑中只有一个模糊的点子，准备重新构建一个模块。我不知道确切该怎么做，只是确信当前的模式并不理想。 于是我启动了Claude Code。 并不是因为它是“最好的”选择——而是因为我需要一种“自言自语”的方式，一个能理解上下文的助手。我告诉Claude：“这个服务的职责太多了，帮我拆分它。”随即，一场对话开始了。它提出一种分离方案，我讨论修改它，我让它探索另一种可能性，它在动手之前还会展示diff。这是一种协作的过程。 三个小时后，模块被成功拆分，测试通过，设计也有所改进。但这是我的Claude配额的40%。而我还列了一堆机械性任务，比如更新集成测试、清理无用的import、重整目录结构。 然后我打开了Codex。 我给它任务，设置为全自动模式，然后悠闲地去吃午饭。 数据揭示的模式 几个月来，我使用一款菜单栏应用监控自己的使用情况，这款工具记录了会话、token用量及耗时。以下是统计数据： Claude Code: 165次会话，160,893条消息，28,052次工具调用。使用模型：Opus 4.5和Opus 4.6。从缓存中读取了56亿token。 Codex CLI: 27次会话。使用模型：GPT-5.4。模式：danger-full-access，审批策略：never。 令我意外的首先是Claude Code的使用时间分布： 09:00 1 ▏ 10:00 5 ██ 11:00 10 ████▌ 12:00 14 ██████▎ 13:00 7 ███ 14:00 16 ███████▏ 15:00 21 █████████▍ 16:00 15 ██████▋ 17:00 18 ████████ 18:00 13 █████▊ 19:00 14 ██████▎ 20:00 9 ████ 21:00 10 ████▌ 22:00 8 ███▌ 我70%的Claude Code会话发生在下午，仅22%在上午。 初看这些数据，我还以为自己“清晨用Claude”的理论行不通。但深入分析每个时间段的任务类型后，一切都渐渐清晰。 上午用于探索，下午用于执行 Claude Code的上午会话少但时长较长。这些会话属于设计阶段：“这部分功能应该如何运作？”、“帮我审阅这个计划”、“能不能提供一些其他选项”。这些是一次又一次的讨论，需要反复修改观点，最终达成决定。 ...

想象一下，你聘请了一位才华横溢的咨询师。他拥有两个博士学位，会说七种语言，并能解决你甚至不知道存在的问题。你把他安排到一个会议室，然后告诉他：“我需要你重新设计项目的认证系统。” 咨询师看着你，点了点头，问道：“哪个项目？” 你没有提供代码访问权限，也没有解释其架构。他不知道你在使用JWT令牌还是会话cookie，也不了解你使用的编程语言或微服务数量，更不知道为什么你上一次迁移会失败。 这个咨询师，就像你的LLM（大型语言模型）。而你刚刚犯了90%的AI代理使用者都犯的错误：关注大脑本身，而不是关注大脑所看到的信息。 Prompt工程已经过时——上下文工程长盛不衰 过去几个月，我在每个论坛、每条推特讨论线程、每场团队会议中都看到同样的对话：“GPT-5还是Claude Opus？”“哪个模型对代码更好？”“哪个模型推理能力更强？” 我的回答，每次推算下来，都是一样的：这不重要。当然，不是完全不重要。但一个顶尖模型与另一个顶尖模型之间的差异，与提供优秀上下文和垃圾上下文之间的差异相比，简直微不足道。 一个表现平庸的模型但配备完美上下文，永远优于一个顶尖模型却给它垃圾上下文。总是如此，没有例外。 这就有了一个名词：上下文工程。而且，它与Prompt工程完全不同。 Prompt工程是编写一个好的提示。它是选择正确的词语、结构请求、加入示例。这很重要，但只是一个部分。 上下文工程则是设计模型看到的所有信息：哪些输入信息、顺序如何、空间有限时需要舍弃什么、压缩什么、哪些是必须保留的。这是为LLM做信息架构。 简单来说：Prompt工程是提出一个好的问题。而上下文工程则是在考试开始前决定学生桌上有什么书籍。 四阶段记忆：你看不到的生命周期 OpenAI最近发布了两个Cookbook文章，详细解构了具有长期记忆的代理如何进行上下文管理。这不是RAG，也不是矢量数据库，而是一种基于状态的系统，像一本具有严格规则的田野笔记本。 其模式是“本地优先”和“基于状态”的：一个结构化的状态对象与代理一起更新，贯穿每个阶段。 flowchart TD A["1. 注入阶段\n(会话开始)"] --> B["2. 提纯阶段\n(对话期间)"] B --> C["3. 合并阶段\n(会话结束后)"] C --> D["4. 修剪阶段\n(持久性保存)"] D -->|"新的会话"| A A1["将状态渲染为YAML\n+全局记忆(最多6个)\n+优先规则"] -.-> A B1["save_memory_note()\n验证持久性\n确保可操作性\n拒绝PII和推测"] -.-> B C1["异步任务\n合并会话→全局\nLLM辅助去重\n过滤临时记忆"] -.-> C D1["修剪会话: 最近N次\n注入修剪记忆入\nsystem prompt"] -.-> D style A fill:#2d3748,stroke:#4a9eed,color:#fff style B fill:#2d3748,stroke:#ed9a4a,color:#fff style C fill:#2d3748,stroke:#9a4eed,color:#fff style D fill:#2d3748,stroke:#4aed5c,color:#fff 阶段1：注入——考试桌上的资料 当会话启动时，代理会创建其初始上下文。这不是随机的，而是一个具体结构： YAML前置数据，包含用户状态（如偏好、配置）。 全局记忆列表：最多6个，按最近使用排序。为什么是6个？因为超过6个会相互竞争，导致信息模糊。少即是多。 <memory_policy>块，带有明确的优先规则。 优先规则至关重要：当前输入 > 会话记忆 > 全局记忆 > 同范围内的最新信息。如果用户说“我现在用Vim”，而你的全局记忆却显示“使用VS Code”，则以用户最新输入为准。虽然看起来显而易见，但没有明确规则的情况下，模型有时会选择其“记住”的内容而非用户给出的新信息。 ...