| title | agents 2026 |
|---|
- 以下内容完全是我个人经验，充斥着大量主观呓语。有不同观点欢迎交流。
- 原本这是要拆成 4 篇的内容，我最终决定还是编集在一起发出来，这样内容上也完备一些。文章不包含任何推广内容，也避免过分使用各种营销概念。
- 正文部分没有使用任何 AI 工具辅助创作，所有内容都是我手动输入的，图片由 GPT Image 2 生成。
- 按照“审阅即过时”原则（Reviewing expires the document），本文内容不承诺任何时效性。
2023 年以前，互联网冲浪的一个顶尖技能就是快速利用搜索引擎找到自己需要的信息。我自诩自己还算是擅长这一点，但在 2023 年以后 ChatGPT 代表的大模型出现抹平了这个差距。尽管犄角旮旯里的东西利用搜索引擎还是有价值的，大部分通用知识都可以通过大模型应用来获取了——当然了在这之上其实加强了另外一个技能的要求，即分辨信息真伪的能力。早些年互联网信息泛滥的情况下虽然也充斥着伪造的信息，但相对于大模型凭借幻觉一本正经地现场直编的内容要容易分辨很多。
在现在这么一个 AI 的时代应该怎么做才能不落后呢？
不止一个人这么问过我，或者跟我聊过类似的问题。
这些问题包括并不限于：
- AI 能拿来干什么，怎么与其交互，
- 如何利用它进行二次开发，
- 如何使用 Coding Agent，
- 如何安装和设置龙虾，
- X 是什么，为什么会 Y……
数不清的细节。甚至有些问题我都还没了解过。
但我通常回复的方式就是，去用就好。因为这也是我长久以来的实践方式。我可能不是第一批拥抱 LLM 的人，但根据身边的统计学来看也是比较少数能够较快接触到新的东西然后上手用的人。
我后来直接把这段话置顶在了微博上：
从 2023 年年初到现在的三年多的时间里，大模型看似进化了非常多，但实际其核心的东西并没有太多根本性的演进。虽然技术层面上花式变化，从 ReAct 到 Chain of Thought，从 RAG 到 tool use、到 Model Context Protocol，从 prompting 到 skills、到 harness engineering。但是纯粹的日常工作这些花里胡哨的技术并不能帮到你太多，反倒是需要落地到具体的应用场景上才有真正的施展空间。
当然了，徒增焦虑的事情还是有的，去年的 sipdickdeepseek、今年的龙虾。我不知道多少人因为这些东西被忽悠，甚至是付费体验，然后发现毫无卵用了。
我跟很多朋友一起聊天以后得到了一个还算是共识的结论，我称之为升级对齐定律，或者说升级归零定律。一旦某个底模升级，或者是出现新的应用场景，那大家立马被拉到同一个起跑线上，之前的很多玩法全部归零。当年我们在 Stable Diffusion 2 时代需要花式训练 LoRA、需要到处搜寻和转换提示词，玩得更花的话需要 inpainting 等更花哨的能力——而现在，我只要一句话就能做到我想要的东西。
那是不是我们坐等着到了 AI 到那个地步就行了呢？
我个人觉得没问题，但最好是现在立刻马上就上手使用。大部分的 Chat based 应用是免费的，做一些专业内容的应用一般也都有体验额度。这是当下这个时代的红利。至少日常应用来说，获取信息的效率和文案创作能力能提升很多，在这之上稍微扩展一下就能加速日常工作效率。
一直以来很多人都有一个观点，也就是 AI 替代程序员。
目前看来这件事儿好像还在往前推进。很多人似乎已经很轻松地就能通过 Agent 来构建应用、进行创作或者完成其他方面的任务了。
但是这个很多人是多大范围呢？从身边的统计学来看，我确实能观察到一大堆的案例。但是脱离了程序员或者软件工程团队这么一个特殊的群体，你会发现真正应用上了这堆东西的并不多。哪怕现在 AI 产品如雨后春笋一般冒出来，现在能够被充分利用发挥其效益的还是少之又少。 核心问题始终都在于，AI 真正解决的问题并不是“替代程序员”，而是作为一个更加灵活的工作流编排工具。
只是恰好程序员手上的工作是最容易标准化和自动化的，也就最先迎接了这一波冲击。编程语言相对于自然语言来说更加形式化，也有非常完善和自动化的工具来让 Agent 驱动来进行工作，加上开源时代有足够丰富的语料来进行训练，自然就能成为最先被应用的领域。
当然 Agent 毕竟还是处理自然语言的，于是进一步地被开发出来通过 Long context prompting 来执行任务的能力，进而形成了 Agent Skill 这么一个标准的用法。你只要按照流程构建 Skill 文档，大部分 Agent 都可以按照你设计的流程执行。这一个标准看似只是把某些 prompt 连接在了一起，但其实是个相当强的能力，因为本身 Agent 训练的方式很多时候在传统工作流中需要大量逻辑或者组件来实现的东西，你只需要额外一两句话就可以完成，比如分成多 Agent 并行执行或者从某步骤开始重试。
但是这点上也是有另外的问题的，Agent 的底层毕竟还是基于深度学习，概率模型的底子决定了它在做很多事情的时候是不稳定的，既然你可以灵活地加入一些流程，那他当然也可以灵活地跳过甚至抛弃一些流程。因此在关键的工作流中，使用确定性的执行方式（代码）是必不可少的。
这其实是给我们呈现了这么两种不同的工作流，一种是传统的、确定性的、有一定处理门槛而同时可以被 Agent 辅助完成的确定性工作流 —— 编程。
而另一种就是全新的、非确定性的、所有人都可以直接参与的这种 Agentic 工作流。
后者是现在大模型时代给所有人的红利，但同时也意味着这是个埋很深的坑。因此对于关键的工作流，或者关键的工作流程，很多时候还是不能直接替代。就像目前的大部分 Agent 工具一样，还是得靠 TypeScript 或者 Rust 等来糊，Markdown 还没能完全替代编程语言。
当然非确定性并不一定完全是坏事儿，当你需要用它去做一些创造性工作或者去探索一些东西的时候，能够摆脱你自己的固有视角限制，发现一些新的观点和方向。当然这就又回到了我在前面的内容里说的点，这些东西是否有效、是否属实或者是否能够获取到大量受众，就需要看个人所掌握的工具和能力水平了。
回到文章最开头的那个现象。AI 能否替代程序员呢？我长期持有的观点始终是这个样子的：这个行业最终会被淘汰，但是绝对不是现在这些人吹嘘的“替代”。
随着 Agent 能力的增强其所综合应用编程工具和 Agentic workflow 的能力也会越来越强，编程绝对不再是程序员独有的能力。Agent 能做的事情应该是去自动化任何可以自动化的工作，而编程只是它可以利用的一个手段。所以拥有编程能力，至少借助 Agent 拥有编程能力的人会越来越多，这个角色会越来越不显眼，但是作为实现确定性执行引擎的基础，这部分工作是无法直接替代的。
我从三月份开始一直在尝试使用 Agent 写长篇小说，现在已经在番茄更新了三部，总共超过 100 万字的内容了，虽然本身流量一般但对我来说仍然很有成就感——去年我保持了 100 天连续更新，才总共产出了 10 万字，这种效率已经远胜我了。很多工作流在我看来只要稍作总结就能完全自动化。目前很多人还在糊各种花里胡哨的软件，其实是还沉浸在有了锤子看什么都是钉子的状态。当然对许多人来说这也是件好事儿——总得先用起来，知道它能做什么，再接下来才能更好地利用它。
大部分动态编程语言都会提供一个 REPL，这个概念来自于 LISP，即 Read-Eval-Print Loop。 有一个很形象地表示这到底是在干什么的伪代码：
(loop
(print
(eval
(read))))
任何一个 Agent 其工作流也大概如此：
- 用户输入：接收用户需求、上下文、约束条件
- 思考决策：LLM 自主判断：直接回答 / 需要调用工具
- 工具执行：调用对应工具，拿到外部返回结果（数据、接口、检索内容等）
- 结果校验
- 任务已满足需求 → 进入收尾
- 信息不足 / 未完成 / 结果异常 → 回到步骤 2，多轮迭代
- 轮次限制熔断：设置最大迭代轮数，避免死循环
- 超限仍未完成：梳理当前进度、缺失信息、核心差距（Gap），如实告知用户
- 最终输出：整合全部信息，整理成自然语言结果回复用户
前文我类比了 Markdown（或者说 Agentic 工作流）与编程语言，可以这么说，Agent 就是重新发明了一个非确定性的 REPL（哪怕所谓 Ralph-Loop，本质也不过如此）。
在重新发明 REPL 之外，Agent 还重新发明了 Scheduler —— 这东西在操作系统、云平台已经被发明过两次了。我们前面的内容说过，Agent 无非就是个非确定的工作流执行器，如何根据用户定义的任务来调度、执行和管理这些工作流，就成了诸如 OpenClaw、Hermes 之类的工具要做的另外一件事情。
除此之外还有什么呢？没了。
任何在之上加入的东西都是花活——至少目前来看帮助不大。
一个例子比如 Multi Agent，稍微有点经验的人就知道按照工作流拆分多 Agent 这种事情有多蠢——如果相互之间都有上下文依赖，这种拆分方式只是徒然让流程拉长而且中间因为沟通不畅造成更多不稳定的问题——毕竟信息传递就会有概率丢失，更何况 Agent 本身就是非确定性的。反正现在的 Context 已经足够大到 1M 了，不是异常复杂的工作流几乎也用不了多大的。毕竟 Bill Gates 当年就说过，640k ought to be enough for anybody （不是
还有一个例子就是 Memory——简单来说，一个规划合理的项目结构完全不需要这东西，而简单的任务又根本不会使用多大的 context，所以这种花哨的东西在目前来看除了让 OpenClaw 等之类的 bot 记得你叫什么之外，没什么实质性的用处。我自己构建的 Agent suite 就完全抛弃了任何 memory 相关的内容，因为长期来看这东西除了一直增长最后把 context 搞成一团糟，完全不如让他自行使用 rg 直接在 workspace 里实时检索获取最新的一手信息。
可以看看某国产 Agent 的记忆有多糊：
用户名为**，现居上海，B2B SaaS 产品经理，正在为所负责产品规划「**」新功能，目标用户为产品/设计/远程团队。已完成 5 次用户访谈，识别核心需求：简化操作、实时协作、集成链接到其他对象。团队配置 1 前端+1 后端工程师，全职 3 个月，计划 Q2 发布 MVP。竞品对标**和**，定位需比**简单、比**功能更丰富，需兼容现有实时同步架构，移动端支持不重要。同时以笔名**创作**小说三部曲，当前编辑第 71-79 章，作品围绕**、**两位主角以 POV 视角叙事，呈现**家族兴衰。采用 SOUL.md 角色文档和记忆更新系统维持剧情连续性。此外处理财务文档工作，需产出多格式 Office 输出（PDF/Excel/PPT/Word）……
这种把用户当成俊福来对待的记忆系统真的完全没必要，除了污染上下文没有任何好处。
所以我觉得 Agent 这件事情上还是会回到所谓的升级对齐定律：当大模型基座的能力足够强，context 足够大，token 足够便宜的时候，Harness Engineering 也就成了摆设。所谓一力降十会，花活再多也不如一个量大管饱的 REPL 让大模型自己干稳妥。
让我们再把时间线拨回三年前。
当年我们还在用各种方式分享 Prompt 模板、Stable Diffusion 关键词、最后搞出来 Chain of Thought，然后 Model native reasoning 出现了，一切都不用再麻烦了。
为了接入工作流，最开始我们是用 prompt 来给示例要求输出结构化结果、然后是允许 prompt 一组 schema 让大模型输出结构化结果、然后是 tool use / tool call，然后是 model context protocol 来链接 Chat based 大模型软件和工具，最后完全进展到只通过 Markdown 和少量脚本来实现的 Agent Skill。
为了 Feed 更多的领域知识，最早我们做的是直接塞进 prompt，因为内容量太大于是有了 RAG，再之后是提供工具或者 MCP 让大模型主动检索，最后变成直接扔一个目录和 Playwright （Chrome） MCP 让 Agent 自行去获取信息。
这个系列里我几乎每一篇都在强调升级对齐定律，这里就不再特别说了。而我今天想说的是，到底哪些变了，哪些没变。
变了的是上下文——这里并不只是那个 8k-1M 的 token 容量，而是模型以及所有能够获取到的输入。
- 早期的模型能力不足，我们需要 Prompt Engineering 来编排模型能够理解的输入，得到我们预期的输出。而现在 reasoning 能力都已经是 model native 了，我们需要的操作只是把我们想要的东西告诉目标模型就 OK 了。
- 早期的模型 context 不足，我们需要考虑提供合适的准确的信息就要精细控制上下文中填充的内容，需要 embedding 和 RAG，需要精细设计 tools 的输入输出来优化 token 占用。现在 128k 是入门基础，256k 是大部分主流模型能够做到的，少部分 SOTA 模型已经能够提供 1M 的 context。
- 早期模型的参数量比较小，后期逐渐提升了训练规模，并且加入了很多针对性的优化，并且扩展了工具调用了 agent 能力，这种情况下的模型完全能够自动化地去完成相应任务。
- 早期的应用只有一个单纯的 Chat UI，API 也只能支持 message 输入，tool use 能力增强以后逐渐出现了功能更加丰富的客户端以及 TUI 的 Agent，除了文本、文件上传和图片以外，这些工具可以直接访问你系统信息、读取文件系统、执行命令和访问网络。
- 涉及到在线的大模型服务，这方面的能力也都在提升——可以检索网络信息、可以与某些开放的工具交互，然后 会根据你的历史消息记住一些东西——当然这件事情不一定是好事儿，就像我前面提过的，记忆系统现在相当不成熟，哪天你在 Gemini 问过一次脚气怎么治，接下来的聊天里他可能时不时地冒出来关心你的脚气问题。
这是变了的东西——大模型或者 Agent 的知识储备越来越丰富、获取信息的渠道越来越多、拿到的结果也越来越准确、能够一次性容纳更多的内容来获取更加全面的上下文。
没变的是什么呢？Prompting。
不是单纯的“Prompt”，而是一套 Prompting 规则。长期以来我们看 Prompt Engineering 好像是在如何提供更多的信息给到大模型让他来按照我们的意图生成内容，但其实这个思路一定程度上是反过来的。我们提供的各种信息，更多的是限制大模型不让他过度发散，而是使用我们预期的方式来完成任务——因为现有规模参数量的情况下，我们所能提供到的信息甚至不如它自己编造的丰富，因此让它们按照我们预期的方式来工作的办法就是提供准确、清晰而且具体的规则，让他们按照规则来做事情。
你会发现从 Prompt Engineering 开始我们其实就是在这样做，一直到现在。无论是 AGENTS.md 规范，还是 Agent Skills，还是其他什么花样的操作，其实都是在遵循同样和类似的原则。
说到这儿再插一个题外话，前面我说过记忆系统不靠谱，另外一个不靠谱的东西就是各种抽象技能——前面那一章 Nondeterminism considered harmful 之外我本来还想写一个 Abstraction considered harmful 来着，但是现在看这部分内容在本章里提一句就行了。如果一个 Skill 写得很抽象，其结果就是起不到任何作用，或者是与预期效果造成严重偏离 —— 以当前的情况来看，你等待 Agent 通过 SKILL 来进化还不如等待底座模型升级。
举个例子，我那个编写小说的 SKILL 并没有什么花哨的东西，就是具体如何构建大纲、角色、和编写小说的指导，也没有任何记忆系统或者所谓的什么抽象思考能力，但是每一篇小说在我这边都有一个严格的标准结构：
README.md
STYLEGUIDE.md
00-intake/
01-brief/
02-research/
03-foundation/
souls/
04-outline/
05-rules/
06-analysis-research/
07-writing/
samples/
chapters/
08-operations/
logs/
feedback/
retrospectives/
change-log/
09-assets/
10-publication/
11-quality/
99-archive/
samples-YYYYMMDD/
import-YYYYMMDD/
有些人说这就是所谓的 Harness Engineering —— 其实归根结底还是 Prompting，某些东西不用过多的文本解释，因为 Agent 能够识别和理解项目结构，而只要你项目管理能力就能很好利用这点。
说这么多，我觉得重点就这么几条吧：
- 抓住一切可以利用的机会和手段开始用起来各种 AI 工具和 Agent。
- 不要焦虑，也不要过度追捧营销概念。
- 尝试构建自己的工具、工作流和 SKILL，多了解和积累相关的经验。
- 认清本质，接受技术升级带来的工作和生活方式改进。
以上。