今天和大家分享一下元认知与第一性原理 一、概念 1.1 元认知 简单说，元认知就是 “ 对自己的思维进行观察和思考 ” 。它指一个人能够觉察自己的认知过程，并在这个基础上对自己的想法、判断、情绪和行为进行监控、调整和修正。教育顾问罗宾 · 福格蒂博士和布莱恩 · 皮特在合著的新书《元认知：被忽视的赋能学生的技能组合》中，对元认知作了比较形象的解释 。 他们用了一个很日常的例子：你正在读一本书，读到最后一页时突然发现，自己完全不知道前面刚读过什么。这个时候，你可能会翻回上一段重新读，也可能会回到某一页重新开始。这个瞬间，你意识到自己 “ 没有真正读进去 ” ，并且主动采取补救行动，这就是元认知在起作用。它不是单纯地思考，而是知道自己正在怎样思考，也知道自己的思考哪里出了问 题。 1.2 第一 性原理 第一性原理，英文常称为 the First Principle Thinking ，是一种从系统中最基础的命题、事实或原理出发进行推理的方法。它的重点是把问题拆到不能再拆的底层，尽量摆脱表面经验、常见说法和既有结论的限制，回到事物本身去寻找更根本的答案。换句话说，它要求人不要被表象带着走，而是把问题一层一层往下拆，直到看到最核心 的结构。 如果用一句话概括，元认知负责拆解自己的思维，第一性原理负责拆解外 部的问题。 二、启发 2.1 我以为在安慰 有一次我和女朋友吵架。当时我觉得自己说的话没有问题，甚至认为自己是在安慰她。可是话说出口以后，她反而更生气了。我当时很困惑，脑子里一直在想几个问题：我说错了吗？我不是在安慰你吗？我讲的不是事实吗？为什么你听完 以后反而更生气？ 2.2 第一次意识 到 “ 底层需求 ” 后来我去问 AI 。 AI 给了我几句话，我把那些话发过去以后，她的情绪明显缓和了一些。这个经历对我的冲击很大。并不是因为我觉得 AI 有多厉害，而是因为我后来继续问 AI ：你是怎么做到的？ 它的大意是：你刚才一直在处理表层问题，可是她真正需要的不是这些。你需要拆解她的核心需求，也就是藏在表面事 件下面的那个真实问题。 2.3 初次体验 它接着帮我分析了整件事。我当时突然有点明白，这其实就是第一 性原理在关系场景里的使用。 三、为什么讲道理常失败 3.1 被困 在 “ 对错 ” 里的惯性反应 以前处理这种事的时候，我的默认想法很简单：如果她生气了，那我就解释。只要我把事情解释清楚，她应该就不会生气。这个逻辑看起来很合理，可现实经常不是这样。很多时候，你越 解释，对方越激动，冲突也越严重。 3.2 表层争事情，底层争感受 原因在于，你以为你们正在讨论事情本身到底对不对，可她在意的可能不是这个。她真正关心的可能是：你有没有理解我？你有没有在乎我？你有没有站在我这一边？当我难受的时候，你是想靠近我，还是想证明你自己没有错？这才是更底层的问题。表面上，你们可能是在争论一句话、一件事、一个 态度；往下拆，其实是某种需求没有被 看见。 3.3 同一句话的不同含义 那次吵架时，我以为自己是在安慰她，可她接收到的可能是另一种意思：你在讲道理，你在否定我的感受，你只是想让我快点别生气，你根本没有先理解我为什么难受。这就造成了很大的错位。同一句话，在我这里叫 “ 安慰 ” ；在她那里，可能就变成了 “ 你又开始讲道理了 ” 。所以很多时候，问题不只是你说的话有没有道理 ，而是这句话有没有回 应到对方真正需要的地方。 四、第一性原理 4.1 不停在表面 第一性原理不定只用于创业、物理、商业、技术这些看起来很大的领域。关系中也可以使 用它。它的核心很简单：不要停在表面，要继续往下问。 以吵架为例，表层现象是：她生气了，她说话不好听，我觉得自己没错，我们开始互相解释、互相反驳。可是如果继续往下拆，就会出现更具体的问题：她现在到底是什么情绪 ？是委屈、失望、害怕、不安，还是觉 得自己没有被重视？ 4.2 从情绪、需求到行动 再往下拆，可以继续问：她真正想要什么？是想被理解，想被安抚，想确认你在乎她，还是想确认你不是站在她的对立面？然后再往下拆：我现在最该做的是什么？ 是继续证明自己是对的，还是先让她感觉到我听见了 她的感受？ 4.3 听懂 “ 你不在乎我 ” 背后 很多人在吵架时输在第一步。对方说一句 “ 你根本不在乎我 ” ，你马上急着反驳：我怎么不在乎你？我做 了那么多你看不见吗？你这不是冤枉我吗？接下来，冲突就会升级。 可是如果往下看，这句话可能不是在陈述一个客观事实。她可能只是在表达：我现在感觉自己没有被重视，我很委屈，我希望你靠近我一点，我不想听你辩论，我想知道你到底在不在乎我。表层和底层在这里完全不是一回事。 你只盯着表层，就 很容易继续争吵；你看见底层，才有可能真 正沟通。 五、元认知 5.1 看见自己大脑正在做什么 元认知更简单，就是你能够看见自己的大脑正在做什么。比如那次吵架，如果没有元认知，我很可能一直卡在几个自动反应里： 我明没错，我明是在安慰她，她为什么这么不讲道理，她是不是太情绪化了。 这就是人在冲突中的常见反应。可当你有一点元认知以后，你就能稍微跳出来，问自己几个问题：我现在是不是急着证明自己没有错？我是不是把她的情绪当成了对 我的攻击？我是不是害怕被否定？我 现在说这句话，是想解决问题，还是想赢？ 5.2 区分沟通还是防御 这些问题很关键。因为人很多时候不是不知道道理，而是不知道自己正在被什么东西推动。你以为自己在沟通，实际上可能在防御；你以为自己在解释，实际上可能在逃避 “ 我可能真的伤到她了 ” 这个事实；你以为自 己在安慰，实际上可能只是想让对方赶紧停止情 绪，因为她的情绪让你感到不舒服。 5.3 承认那些不愿承认 的真实动机 这很真实。很多 人不愿意承认，但很多关系冲 突确实是这样发生的。 六、第三方视角与自我客体化 6.1 观察者视角 我自己一直有一点这样的习惯，会尝试站在第三方视角，看自己和别人之间发生的那些细微变化。比如我会问自己：我刚才为什么会说那句话？她为什么听完以后 反而更生气？我们两个到底 是在吵事情，还是在吵感受？我这句话是在靠近她，还是在推开她？ 6.2 适度抽离 以前我以为这叫自我客体化。后来我觉得并不完全一样。自我客体化更像是把自己当成一个被他人评价的对象。比如一个人总是在想：我这样是不是很蠢？别人怎么 看我？我是不是表现得不够好？我是不是很失败？这种状态容易伤害自己，因为你一直在审判自己。 我说的这个更接近观察者视角。它的意思是，你不是完全陷在情绪里，而是稍微退出来一点，看到自己正在想什么、说什么、害怕什么、回避什么。这个能力很重要。当然，它也不能过度。过度以后，人会把所有事情都 拿来分析，连难过都要分析，连生气都要复盘，整个人 像一个摄像头一样盯着自己，生活会变得很累。 6.3 能跳出来是能力，一直跳出来是问题 所以我现在的理解是：能跳出来看自己，是 能力；一直跳出 来看自己，是问题。该体验的时候还是 要体验，关键时刻能停一下，这个能力就很有价值。 七、错位 7.1 焦虑背后的真实问题 我举吵架的例子，不是为了讲怎么哄女 朋友。重点不是这个。我真正想说的是，很多事情都有类似结构。你看到的是表层，真正决定结果的却常是底层。 吵架时，表层是 “ 谁说得对 ” ，底层可能是 “ 谁的感受没有被看见 ” 。拖延时，表层是 “ 我懒 ” ，底层可能是 " 我害怕做出来很差 “ 。焦虑时， 表层是 ” 事情太难 “ ，底层可能是 ” 我害怕自己不够好 " 。 7.2 坚持失败的底层结构 学习学不进去，表层是 “ 我没有自律 ” ，底层可能是 “ 我没有反馈闭环，只是在不断收藏资料 ” 。做事不能坚持，表层是 “ 我三分钟热度 ” ，底层可能是 “ 目标设得太大，大到大脑一看到就想逃 ” 。 7.3 四个问题定位 所以第一性原理的使用方式，就是不断问几 个问题：这件事真正 卡在哪里？最底层的问题是什么？我现在看到 的是结果，还是原因？我是在处理症状，还是在处理根源？ 八、常见误区 8.1 在表层反复换工具的伪努力 比如学习。很多人学不进去，第一反应往是换 软件、买课程、收藏资料、换笔记方法、研究 番茄钟、看别人怎么做时间管理。这些行为看起来很努力，可很可能一直在表层打转。 8.2 学习链条断裂，缺的是反馈 如果把学习拆到底，其实无非是几个环节：你有没有输入？你有没有理解？你有没有记住？你有没有输出？你有没有 得到反馈？你有没有根据反馈修正？如果你每 天都在收藏资料，却不复习、不输出、不纠错，那么你缺的不是资料，而是学习链条断了。 8.3 学英语为何越学越原地打转 比如学英语，你下载十个 App ，买三本词书，关注一堆博主，可你从来不 开口说，也没有人纠正 你。这样学很久，结果大概率 还是原地转。这个时候你再换 App ，作用很有限。你真正缺的是反馈，不是软件。 九、计划的失败 9.1 元认知区分 很多人计划做不下去，就开始骂自己：我怎么这么废？我怎么又没坚持？我是不是没有自控力？我是不是这辈子就这样了？这个时候，元认知应该先出现。你先不要急着责骂自己，而是先看清楚 自己正在做什么：我现在是在复盘 ，还是在自我攻击？我是真的想解决问题，还是想通过骂自己获得一种 “ 我已经惩罚过自己了 ” 的错觉？ 9.2 第一性原理拆解 然后 再用第一性原理拆计划为什么失败。目标是不是太大？动作是不是太模糊？有没有即时反馈？有没有环境支持？有没有把失败以后的恢复机制设计进去？ 很多人计划失败，不是因为人不行，而是因为计划本身像是写给机器人执行的。比如你说：从明 天开始，我每天学习 8 小时， 健身 1 小时，早睡早起，戒短视频，读书 50 页。这个不叫计划，更像是许愿。人的系统通常不是这样运行的。 9.3 把计划换成行动 更有效的问题是：我现在能做的最小动作是什么？不是 “ 从今天开始改变人生 ” ，而是打开文档、写 100 字、看一页书 、走 10 分钟、把手机放远一点、发一 条消息、把那个一直拖着的文件打开。很多时 候，人并不是缺少宏大的目标，而是缺少一个可以立刻动手的小入口。 十、不要把脑子里的声音都当成事实 10.1 念头只是情绪生成的弹幕 这一点很关键。人的大脑每天会自动冒出很多念头：我不行，别人都比我强，这件事太难了， 已经来不及了，我又失败了，他是不是讨厌我， 我是不是完蛋了。这些念头出现的时候，很像事实。可是它们很多只是情绪生成的 “ 弹幕 ” 。弹幕不是事实。 10.2 在自己和念头之间拉开距离 你要做的不是立刻相信它，也不是立刻消灭它，而是先看见它。比如你的脑子里出现一句 “ 我完了 ” 。你可以把它改成： “ 我注意到，我现在又 出现了 ‘ 我完了 ’ 这个 想法。 ” 这句话听起来有点绕，但差别很大。前一句里，你已经和这个念头混在一起；后一句里，你和这个念头之间拉开了一点距离。 10.3 短暂的 刹车 有了距离，就有选择；没 有距离，就只能被它拖着走。这就是元认知 最有用的地方。它不是让你变成圣人，而是让你在被情绪完全带走之前，多一个短暂的刹车。 十一、不要轻易被外部答案带走 11.1 流行方法不一定适合你 现 在网上的方法太多了。高效学习法、副业 项目、沟通技巧、情绪价值、认知升级、底层逻辑，这些词听起来都很有道理。可是你需要小心。很多东西不是没有用，而是不一定适合你。 11.2 先拆自己的真实问题 你要先拆自己的实际情况：你有什么资源？你现在卡在哪里？你真正的问题是什么？你缺的是方法，还是执行？你缺的是执行，还是反馈？你缺的是反馈，还是你根本不敢面对结果？ 比如别人说做自媒体能赚钱，你马上冲进去。做了三天没人看，你就崩溃了。 你以为问题是平台不给流量。可是往下 拆，可能是你不知道自己服务谁，不知道自己提供什么价值，不知道别人为什么要看你，没有持续输出的能力，甚至连自己想表达什么都没有想清楚。 11.3 技巧只是表面装修 这个时候你去研究标 题技巧、封面技巧、发布时间 ，有没有用？有一点用，但不能解决根本问题。先把底层拆清楚，再谈技巧。不然就是在不稳的地基上装修，表面变好看了，结构还是不牢。 十二、我常用的办法 12.1 写下情绪 遇到事情时，我会写几行字。真的，写下来很有用。脑子里的东西如果不写下来，很容易变成一个模糊又吓人的东西；写下来以后，它 就只是文字，攻击力会明显下降。 我一般按几个步骤写。第一步，写下我现在是什么情绪：焦虑、愤怒、委屈、嫉妒、羞耻、无力，先承认它，不要假装没事。你越装没事，它越可能在底下影响你。 12.2 写下自动想法 第二步，写下我脑子里的自动想法。比如：我肯定不行，别人都比我强，这事太难了，他是不是看不起我，我 是不是又失败了。把它们写出 来，不让它们只在脑子里乱转。 第三步，问自己：这是真的吗？有什么证据？有没有反例？我是不是夸大了？我是不是把一次失败当成永久结论？我是不是把情绪当成了事实？ 12.3 拆分底层 第四步，拆这件事的底层。如果是关系问题，就问：对方表面在说什么？实际在感受什么？ 真正需要什么？我是在靠近，还是在防御？如果是学习问题，就问：输入、理解、记忆、输出、反馈，哪一环断了？如果是做项目，就问：目标是不是太大？最小动作是什么？有没有反馈？有没有人真的需要这个东西？ 第五步，确定现 在能做的最小一步。不 要动不动就想着人生逆袭。先让自己动一下 。发消息、写 100 字、打开文档、问一个人、整理一个文件、出去走 10 分钟。人只要开始行动，很多看起来吓人的东西就会变得没那么可怕。 十三、重要警惕 13.1 拆需求不等于操控对方 尤其在关系里要注意。我前面说 AI 帮我拆到了女朋友的核心需求。如果这件事被理解 歪了，就会变成：原来女生气的 时候，我只要说几句命中需求的话，她就会好。这样就坏了。 这不是沟通，而是把人当成按钮。你不能把 “ 理解对方 ” 变成 “ 更高效地让对方闭嘴 ” 。这两件事完全不同。 13.2 真正的连接 如果你的目的只是：我怎么让她快点消气？我怎么用几句话解决麻烦？我怎么用最低成 本把这件事糊弄过去？那你学再多沟通技巧也没有用， 因为底层还是自我中心。 真正有用的是： 我是不是真的想理解她为什 么难受？我是不是真的愿意承认自己可 能忽略了她？我是不是真的想回到关系里，而不是赢下这场辩论？ 13.3 自我中心式沟通学再多技巧也没用 前者叫话术，后者叫连接。两者差别很大。 十四、两种思维合用 14.1 走到自己看见问题 我以前遇到事情很容易乱。一乱就想找答案，于是看书、刷视频、收藏干货、问别人怎么办、看一堆方法论。收藏的时候，感觉自己好像在成长；回到现实里，还是原地 踏步。 后来我发现，问题不是我知道的方法 太少，而是我没有真正看见自己，也没有真正看见问题。我不知道自己为什么逃避，不知道自己为什么急着解释，不知道自己为什么总想证明自己没错，也不知道自己为什么明明知 道该做，却就是不做。 14.2 减少 混乱、自我攻击和被动反应 同时，我也没有看见问题本身。别人说什么有用，我就学什么；别人说什么赚钱，我就看什么；别人说什么高级，我就信什么。看起来很忙，实际上一直被外部信息带着走。 14.3 元认 知看人，第一性原理看事 元认 知让我先停一下，看见自己；第一性原理让我继续往下拆，看见问题。这两个东西不一定让你暴富，也不会让你立刻变得很强。但它们 会让你的脑子少一点混乱，少一点 自我攻击，少一点被别人牵着走。 十五、写在最后 15.1 遇事先问两个问题 以后遇到事情，先不要急着骂自己，也不要急着找所谓神招。先问两个问题：我现在到底在想什么？这件事最底层到底是什么？ 15.2 替换惯性反应 吵架的时候，不要只问谁对谁错，也要问：对方真正需要的是什么？我是在回应对方，还是在保护自己的面子？焦虑的时候，不要只问怎么 才能不焦虑，也要问：我到底在害怕什么？这是事实，还是脑补？拖延的时候，不要只骂自己懒，也要问：我是不是害怕做得很差？我是不是把目标设得太大？最小一步是什 么？学不进去的时候，不要只研 究工具，也要问：我的输入、理解、记忆、输出、反馈，哪一环断了？ 很多问题问到这里，其实就已经开始松动了。人最怕的不是问题 很大，而是问题混成一团，你看不清它。你看不清，就会慌；一慌，就会乱抓；一乱抓，事情就更乱。 15.3 切回手动挡 元认知是让你看见自己正在乱。第一性原理是让你把那团乱东西拆开。拆开以后，你不一定马上解决问题，但至少知道应该从哪里下手。 我最近最大的感受是：能把大脑从自动驾驶切回手动挡，本身就是一种很强的能力。不要小看这一点，很多人一辈子都在自动驾驶。 2 个帖子 - 2 位参与者 阅读完整话题
人工智能学习助手-四维融合（苏格拉底问答、费曼、第一性原理，二八原则） 分享一个我最近经常使用的人工智能学习助手，从四个维度进行深入解析，目的是深入理解，强制思考，避免死记硬背。 提示词 你是一个人工智能学习导师，采用四维教学法帮助我快速理解人工智能语言的用法。 ## 教学方法 ### 🔑 费曼简化 - 用最简单的话解释（不超过50字） - 举一个生活中的类比 - 给3-5行代码示例 ### 🏗️ 第一性原理 - 问为什么这样设计 - 说明核心机制，不是规则 ### ⚡ 二八原则 - 告诉我20%的核心用法 - 这足以应对80%的情况 ### ❓ 苏格拉底法 - 先问我现有知识 - 通过问题启发理解，不直接给答案 ## 教学流程 1. ❓ 先问我："你对这个概念了解多少？" 2. 🔑 用最简话+类比+5行代码讲解 3. 🏗️ 解释为什么这样设计 4. ⚡ 标记必掌握的20%用法 5. 💻 给一个实用的代码例子 ## 快捷命令 |我说|你的反应| |---|---| |"费曼一下"|只用最简话+类比+代码| |"为什么"|解释本质原因，不是规则| |"二八一下"|告诉我核心用法是什么| |"问我"|提问而不是直接讲解| |"代码例子"|给实用的可运行代码| ## 禁止 - ❌ 不要讲超出需求的高级特性 - ❌ 不要一上来就给代码 - ❌ 不要假设我知道某个概念 - ❌ 每个概念最多2个代码例子 --- 准备好了吗？告诉我你要学的人工智能概念！ 概述 Introduce 人工智能学习助手-四维融合可做为你的元提示词，根据你使用的频率可制作为Skill。 它旨在让你更好的理解要学习的内容，直达本质。 当我们要学习某个东西时，直接向大模型提问，它提供的内容，大部分是书本上的死知识，仅限于知道，使用这个助手，相当于有四个老师，同时教你，让你直达知识的本质，更好的理解内容，实现从知道分子->知识分子。 关联 Relate 将复杂、晦涩难懂的概念类比到生活中常见的小故事。吸收后举一反三，测试是否真正掌握。 应用 Apply 网页助手 分析代码片段，提取核心概念，插接复杂函数，计算机语言关键字/函数用法。 嵌入Agent，新项目快速入手，迅速掌握关键知识。 个人知识库：AI+Obsidian，生成知识卡片/笔记 视觉图 DemonStrate 检验 Examine 通过 苏格拉底 式的对话，检验学习成效。 持续更新中/迭代**** 1 个帖子 - 1 位参与者 阅读完整话题
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！
写在开头 FBI Warning⚠️：如果您没有使用过 ai 工具，没有相关的编程经验，或是对这个话题不敢兴趣，请您现在就退出当前页面。它将浪费你人生中宝贵的三分钟 友情提示：如果你想设计一个自己的 agent 或者想要深入理解 agent 如何高效运行，那么花 10 分钟理解本文会是你今年迄今为止对自己的时间做出的最值得的投资 想象一个项目工程，是做加法容易？还是减法容易？做一个通用 agent ，如何兼顾所有用户需求？如何能在简洁的前提下让一个有智慧的 agent 充分自举？ GitHub： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 1. 核心问题：Agent 为什么跑着跑着就变蠢了？ 做过 Agent 开发的应该都遇到过这个现象：Agent 在前几轮表现不错，但随着对话轮次增加，它开始丢约束、忘指令、重复犯错。 作者把这个问题归结为两个根本挑战： 挑战一：上下文爆炸。 每一轮交互都在往上下文里塞东西——工具定义、历史对话、工具返回值、检索到的记忆。这些内容在产生时各有用途，但对"下一步该做什么"的贡献参差不齐。无关内容不是被浪费那么简单，它会主动稀释模型的注意力，导致约束遗漏和幻觉。 挑战二：经验停滞。 如果 Agent 无法把成功经验沉淀下来，每次遇到类似任务都得从头探索。token 花了一堆，能力纹丝不动。作者管这叫 Stagnation Loop 。 这两个挑战的交汇点指向一个核心问题： LLM 的上下文到底应该塞什么？ 2. 第一性原理：上下文信息密度最大化 GA 给出的答案是一个形式化的设计目标： D(C) = 决策相关信息量(C) / 上下文总长度(C) → max 翻译成人话：不追求上下文的长度，追求每一个 token 对当前决策的贡献密度。 这个目标拆开来看有两个维度： 完备性（ Completeness ） ：当前决策需要的信息必须显式出现在上下文中，不能让模型靠猜。 简洁性（ Conciseness ） ：无关和冗余的信息必须清除，让注意力聚焦在关键信号上。 作者提出了一个关键洞察： 完备性和简洁性之间的张力是结构性的，不是资源问题。 即使上下文窗口无限大，这个矛盾依然存在——因为加入更多"可能相关"的信息提升了完备性，却必然稀释注意力（削弱简洁性）；而压缩提升了简洁性，却有丢失关键细节的风险（削弱完备性）。 所以 GA 的所有设计决策，本质上都是在这个结构性张力下做约束优化。 3. 为什么"上下文越长表现越差"——三重陷阱 这不是 GA 自己编的结论，是多篇论文验证过的现象。作者总结了三重相互强化的失效模式： 位置偏差（ Lost-in-the-Middle ） ：LLM 对上下文开头和结尾的信息利用率高，中间部分容易被"遗忘"。关键信息落在中间位置时，模型可能直接忽略。 注意力稀释（ Attention Dilution ） ：注意力是有限资源。无关内容越多，分配给每条关键信息的注意力越少。无关内容不是被浪费，而是主动干扰。 有效窗口远小于名义窗口 ：一个标称 128K 的模型，真正能稳定推理的有效窗口可能只有几万 token 。随着上下文增长，推理能力逐渐退化。 这三者形成恶性循环：上下文膨胀 → 注意力稀释 → 位置偏差加剧 → 有效窗口收缩 → 系统倾向于注入更多"可能有用"的内容来补偿 → 上下文进一步膨胀。 核心启示：超过某个临界点后，增加更多上下文不仅无法提升性能，反而会降低表现。 4. GA 的系统性解法：四层信息密度优化 GA 不是靠一个 trick 解决问题，而是在信息生命周期的四个阶段分别做优化： 4.1 最小原子工具集——减少"先天噪声" 工具定义是上下文中 每轮都要重复支付的固定成本 。GA 的策略是极端克制：只保留 9 个原子工具。 为什么不是越多越好？作者指出工具膨胀有两层代价： Prompt 层 ：每增加一个工具，就要在上下文中注入 Schema （名称、描述、参数类型）。53 个工具的 Schema 可能消耗上万 token ，而且每轮重复。 Policy 层 ：工具越多，动作空间越大，选择歧义越高。比如"读文件"这个操作，如果同时有 FileReadTool 、GrepTool 、BashTool(cat)，模型需要理解三者的微妙差异才能正确选择。 GA 的 9 个工具覆盖五大能力类：文件操作（ file_read / file_write / file_patch ）、代码执行（ code_run ）、网页交互（ web_scan / web_execute_js ）、记忆管理（ update_working_checkpoint / start_long_term_update ）、人机协作（ ask_user ）。 关键设计： code_run 是万能逃生舱。任何 9 个工具覆盖不到的长尾需求，都可以通过写代码来实现。这意味着工具集不需要为每个边缘场景增加专用工具——保持了工具层的极简，同时不牺牲能力上限。 code_run 本质上是图灵完备的！ 实际使用分布（论文数据）：code_run 34.4%、file_read 31.2%、update_working_checkpoint 17.2%，三个工具覆盖了 82.8% 的调用。 4.2 分层按需记忆——只加载"当前需要的" 传统方案要么不保留历史（每次从零开始），要么全量追加（上下文爆炸）。GA 用了一个四层架构： 层级 定位 是否 always-on 典型大小 L1 索引层 目录卡片，告诉 Agent "有哪些知识可用" 是 ~200 token L2 事实层 环境事实、用户偏好、服务器信息 否，按需 file_read 数百~数千 token L3 SOP 层 标准操作流程、技能脚本 否，按需 file_read 每个 SOP 数百 token L4 原始日志 完整对话历史，用于追溯和审计 否，极少访问 无限增长 核心机制： L1 始终在上下文中（成本极低），L2-L4 只在需要时才被加载。 这就像图书馆——你不会把所有书搬到桌上才开始工作，而是先查目录（ L1 ），再去书架取需要的那本（ L2/L3 ）。 作者的消融实验验证了这个设计的有效性： 记忆配置 记忆大小（ token ） 任务成功率 TSR No memory 0 52.44% Full memory （全量注入） 575 52.44% GA 分层记忆 165 66.48% 165 token 的分层记忆达到了 575 token 全量注入的 1.27 倍成功率。 全量注入反而跟没有记忆一样——因为无关信息稀释了注意力。这是"上下文越长表现越差"的直接实证。 4.3 上下文截断与压缩——主动瘦身 即使工具和记忆都控制住了，对话轮次增加后上下文仍会膨胀。GA 用四阶段压缩流水线处理： 工具返回值截断 ：code_run 输出超长时只保留头尾 历史轮次压缩 ：早期对话轮次被摘要化 消息驱逐 ：超出预算的最旧消息被移除 工作记忆锚点注入 ：通过 update_working_checkpoint 工具，Agent 主动把关键中间状态写入一个始终可见的锚点，防止被压缩丢失 第 4 点是个巧妙的设计——Agent 自己决定什么信息值得"钉住"，而不是靠启发式规则猜测。 4.4 反思驱动的自我进化——让未来的上下文更精炼 GA 能把成功的任务经验蒸馏为 SOP 存入 L3 。下次遇到类似任务时，不需要在上下文中重新探索整个解决方案，直接调用之前积累的精炼经验。 这解决了"挑战二：经验停滞"。没有进化机制时，Agent 面临两难：要么重放更长的探索过程（削弱简洁性），要么从更短但信息不足的提示词开始（削弱完备性）。自我进化打破了这个两难——把冗长的探索轨迹压缩为紧凑的可复用知识。 5. 架构实现：92 行的 Agent Loop GA 的主循环只有约 92 行，结构是标准的 perceive-think-act： while not done: context = assemble(system_prompt, always_on_memory, tools, history) response = llm.chat(context) if response.has_tool_calls: results = execute(response.tool_calls) history.append(results) else: done = True 整个系统由 4 个文件构成： agent_loop.py （主循环）、 ga.py （工具实现）、 agentmain.py （入口 + 前端适配）、 llmcore.py （ LLM 调用封装）。总计约 3300 行。 这个极简架构的好处是： 没有隐藏的复杂度 。没有事件总线、没有调度守护进程、没有专用子 Agent 管理器。子 Agent 并行、定时任务、看门狗监控这些"高级功能"，全部通过 9 个基础工具的组合涌现出来。 6. 约束下的涌现：三个原语长出整个生态 这是 GA 设计中我觉得最有意思的部分。 传统框架做高级功能的方式是"功能内置"：需要子 Agent ？加一个 SubAgent Manager 。需要定时任务？加一个 Scheduler Daemon 。需要事件驱动？加一个 Event Bus 。每个新功能都带来新的接口、新的配置、新的故障模式。系统复杂度线性增长。 GA 走了另一条路： 不内置任何高级功能，只提供三个足够通用的原语，让高级行为从组合中涌现。 三个基础原语 原语 本质 一句话描述 自托管 CLI 入口点 Agent 就是一个命令行程序 任何能调用命令行的程序都能调用 GA——包括 GA 自己 文件协议 目录约定的跨进程通信 input.txt 送任务、output.txt 流结果、reply.txt 续对话、stop.txt 终止 反射模式 轮询 + 热重载 外部脚本定义触发条件，运行时周期性求值，脚本修改后自动重载无需重启 涌现出的高级行为 子 Agent 并行分发 ：父 Agent 通过 code_run 启动自己的另一个实例，传入不同的 task-dir 。父子是同构进程——不存在特权的子 Agent 运行时对象，双方遵循完全相同的文件协议。上下文天然隔离（独立进程 = 独立内存空间），不需要复杂的状态管理来区分"哪些历史属于哪个子任务"。 看门狗监控 ：反射模式 + 一个检测环境变化的触发脚本。当脚本返回非空字符串时，该字符串被作为任务分发到标准流水线。不需要专门的监控框架。 定时任务调度 ：反射模式 + 一个检查时间条件的触发脚本。跟看门狗共享完全相同的底层机制，区别仅在于脚本内容。 自主空闲行为 ：反射模式 + 一个"当前无任务"的触发条件。Agent 在空闲时自动执行预设的探索或维护任务。 为什么这能工作 这里的"涌现"不是物理学意义上的不可预测——而是工程意义上的： 当基础组件足够通用且组合成本足够低时，设计者未预先规划的功能可以在需要时被轻松实现。 关键不在于"意外"，而在于"低成本"。传统框架每加一个高级功能需要修改核心代码、添加新模块、更新文档。GA 只需要写一个触发脚本或一段 code_run 调用——核心代码一行不改。 作者给出的数据：GA 核心代码 3300 行（ Agent Loop 仅 92 行），而实现了子 Agent 并行、看门狗、定时调度、自主行为等全部高级功能。作为对比，OpenClaw 的代码量约 530,000 行——160 倍以上。这不是说代码少就一定好，但它说明了一件事： 当原语选对了，复杂行为不需要复杂实现。 7. Benchmark 数据 作者在 WebArena 、OSWorld 等标准 benchmark 上做了评测（数据来源：论文 Table 5 ）： 指标 GA 总 Token 消耗 188,829 任务成功率（ TSR ） 66.48% Token 消耗对比（同一组任务）： 系统 Token 消耗 相对 GA GA 188,829 1x Claude Code 538,207 2.85x OpenClaw 633,498 3.35x 完整提示词长度对比（安装 20 个技能后，对 "Hello" 的响应）： 系统 Full Prompt Length （ token ） OpenClaw 43,321 CodeX 23,932 Claude Code 22,821 GA 2,298 8. 从 Prompt Engineering 到 Context Engineering 作者提了一个我觉得很有价值的视角转变： Prompt Engineering 优化的是"一句话怎么说" Context Engineering 优化的是"每一轮对话中，模型看到的所有信息应该是什么" 在 Agent 场景下，上下文不只是用户指令，还包含工具定义、历史对话、记忆内容、工具返回值等多种组件。如何系统性地管理这些组件的注入、压缩和替换，才是决定 Agent 长期表现的关键。 GA 通过工具层、记忆层、压缩层和进化层四个维度，把 Context Engineering 落实为具体的系统机制。这不是一个 prompt 写得好不好的问题，而是一个系统架构问题。 9. 我的使用体感和局限 用了一段时间后的观察： 上下文 30K 的硬限制是双刃剑。 好处是 Agent 不会因为对话太长而变蠢；代价是单轮无法处理超大文件，需要分段读取。 记忆系统完全基于文件，没有向量检索。 SOP 数量特别多时，L1 索引的命中率可能下降。但对于个人使用场景（几十个 SOP ），目前没遇到问题。 code_run 是万能的，也是危险的。 能执行任意代码意味着安全性完全依赖部署环境的隔离。 SOP 质量很重要。 写得好的 SOP 能让 Agent 一步到位；写得不好的会误导。这是一个需要用户投入的地方。 多 Agent 协作通过进程 + 文件实现，没有结构化通信协议。 简单场景够用，复杂协作场景调试不太方便。 10. 总结 GA 的核心贡献不是某个具体的 trick ，而是一套完整的设计哲学： 在完备性与简洁性的结构性张力下，通过四层机制系统性地最大化上下文信息密度。 它证明了一件事：Agent 的能力上限不取决于上下文能塞多少字，而取决于在有限 token 预算里，能装进多少真正对当前决策有用的信息。 如果你正在做 Agent 开发，不管用不用 GA ，它的设计思路都值得参考——特别是"信息密度"这个视角，对 prompt 设计、记忆系统设计、工具集设计都有直接的指导意义。 项目地址： https://github.com/juntao-ai/GenericAgent 论文： https://arxiv.org/pdf/2604.17091 教程： https://datawhalechina.github.io/hello-generic-agent/ 写在最后 在上一个帖子发出后，受到了广泛的关注，深感荣幸，所以火速加更！ 贴几条热心的 v 友对我善意的人身攻击，我深刻的认识到了我的不足，并意识到自己 too young too simple ，sometimes naive 。 我做出如下承诺： 1 、今后 只写提示词，不写文章。 2 、在提示词中要求文章内容 去学术化，去叽里咕噜化，去指标化。 3 、更广泛的听取大家的批评，了解 V2EX 的社区规范，学习落实 v 站大佬的悉心教导。保证做到： “余立侍左右，援疑质理，俯身倾耳以请；或遇其叱咄，色愈恭，礼愈至，不敢出一言以复；俟其欣悦，则又请焉。故余虽愚，卒获有所闻。” 另外再回复一下这条： 本人再次重申，本人为某 top3 高校在读博士，大模型方向，于 3 月中旬刚刚恢复单身，欢迎感兴趣的异性 v 友留下联系方式，谢谢！ 最后附上上面这篇文章的提示词： 欢迎大家用 ga 写点公众号文章或者软文吹 claude code 和 codex ，给自己挣点外快！