Agents made simple

大部分动态编程语言都会提供一个REPL，这个概念来自于 LISP，即 Read-Eval-Print Loop。
有一个很形象地表示这到底是在干什么的伪代码：

  (loop
    (print
      (eval
        (read))))

任何一个Agent其工作流也大概如此：

• 用户输入：接收用户需求、上下文、约束条件
• 思考决策：LLM 自主判断：直接回答 / 需要调用工具
• 工具执行：调用对应工具，拿到外部返回结果（数据、接口、检索内容等）
• 结果校验
  • 任务已满足需求 → 进入收尾
  • 信息不足 / 未完成 / 结果异常 → 回到步骤 2，多轮迭代
• 轮次限制熔断：设置最大迭代轮数，避免死循环
  • 超限仍未完成：梳理当前进度、缺失信息、核心差距（Gap），如实告知用户
• 最终输出：整合全部信息，整理成自然语言结果回复用户

前文我类比了 Markdown 或者说 Agentic 工作流与编程语言，可以这么说，Agent 就是重新发明了一个 Nondeterministic 的 REPL。

在重新发明 REPL 之外，Agent 还重新发明了 Scheduler —— 这东西在操作系统、云平台已经被发明过两次了。我们前面的内容说过，Agent无非就是个非确定的工作流执行器，如何根据用户定义的任务来调度、执行和管理这些工作流，就成了诸如OpenClaw、Hermes之类的工具要做的另外一件事情。
除此之外还有什么呢？没了。

任何在之上加入的东西都是花活——至少目前来看帮助不大。一个例子比如Multi Agent，稍微有点经验的人就知道按照工作流拆分多Agent这种事情有多蠢——如果相互之间都有上下文依赖，这种拆分方式只是徒然让流程拉长而且中间因为沟通不畅造成更多不稳定的问题——毕竟信息传递就会有概率丢失，更何况Agent本身就是非确定性的。反正现在的Context已经足够大到 1M 了，不是异常复杂的工作流几乎也用不了多大的。毕竟 billg 当年就说过，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），演示文稿偏好Ocean Gradient配色方案。所有工作独立完成，禁止调用子Agent；质量修复偏好手工重写而非自动化脚本。同时正在进行名为**的项目，并开展**行业商业模式演进与市场动态研究。

这种把用户当成俊福来对待的记忆系统真的有必要用吗？这堆东西塞进context不是明显造成污染吗？

所以我觉得 Agent 这件事情上还是会回到所谓的升级对齐定律：当大模型基座的能力足够强，context足够大，token足够便宜的时候，所谓的 Harness Engineering 也就成了摆设。所谓一力降十会，花活再多也不如一个量大管饱的 REPL 让大模型自己干稳妥。