Skip to main content

acshame

  1. - θ:Foundation Model,模型参数,相当于 Agent 的“大脑”
    - Σ:Scaffold,操作脚手架,包括 prompt、memory、tools 和 control logic,相当于 Agent 的“说明书、笔记本、工具箱和运行逻辑”

    因此两条主线是:

    - Foundation Model Improvement:改“大脑”,慢、深、成本高,但能力会沉淀到模型权重里
    - Scaffolding Improvement:改“外围结构”,快、可回退,不碰模型权重

    下面按你列出的分类介绍。

    ## 一、Foundation Model Improvement 的三种信号

    ### 1. Intrinsic Generative Demonstrations

    朴素理解:让 Agent 自己出题、自己写答案、然后用这些答案自己训练自己。

    这些“演示”并不是外部标注数据,而是模型利用自己已经学到的知识生成的,比如:

    - 指令-回答对
    - 推理轨迹
    - 执行日志
    - 代码和测试

    典型例子:Evol-Instruct、Test-Time Self-Improvement。
    核心风险是“自己教自己”容易陷入模型坍缩、重复已有错误、越练越偏。

    ### 2. Intrinsic Evaluative Feedback

    朴素理解:让 Agent 自己给自己打分、挑毛病、排序,然后拿这些评价去训练。

    与上面的“自己写答案”不同,这一类不是提供示例,而是提供“评价信号”,例如:

    - 分数:一个答案好,一个答案差
    - 偏好:答案 A 比 B 好
    - 一致性:多次采样是否一致
    - 文本批评:指出错误并给出修改建议
    - 自我修正后的答案

    典型例子:Constitutional AI、Meta-Rewarding、TTRL、SELF。
    核心风险是“自己评价自己”可能强化相同偏见,或者学会迎合评价标准而不是真正解决问题。

    ### 3. Extrinsic Exploratory Experience

    朴素理解:让 Agent 出去真实做事,靠环境反馈来改进,而不是自己凭空想。

    学习信号来自“行动之后发生的事”,例如:

    - 单元测试通过/失败
    - 编译器报错
    - 网页状态变化
    - 截图、代码日志
    - 任务奖励、状态转移

    论文又把它分成两种:

    - 真实/沙盒环境交互:直接和代码解释器、网页、GUI、机器人环境交互,例如 Agent-RLVR、WebRL
    - 模拟代理环境交互:先学一个世界模型,再在模拟中探索,例如 WMPO、WebEvolver、WebDreamer

    核心风险是奖励欺骗、稀疏延迟奖励、以及模拟世界模型产生“看起来合理但错误”的状态。

    ## 二、Scaffolding Improvement 的四类修改

    ### 1. Prompt Optimization

    朴素理解:改 Agent 收到的“说明书”。

    因为模型参数不动,改 prompt 是最快、最容易被接受、最容易回退的自改进方式。论文把 prompt 优化分成四种信号:

    - 标量反馈:根据准确率、奖励等一个数字优化 prompt,例如 RLPrompt、BPO
    - 定性反馈:根据自然语言批评或建议修改 prompt
    - 群体进化:生成一批 prompt,选出表现好的,再演化下一代
    - 文本梯度:把“应该如何修改”当作文本方向,像梯度那样指导修改,例如 TextGrad、MetaTextGrad

    ### 2. Memory Evolution

    朴素理解:给 Agent 一个会自我整理、会遗忘、会更新内容的笔记本。

    这里说的 memory 不是模型权重里的参数,而是 外部、非参数化记忆。论文把它拆成三个维度:

    - Memory Object:存什么?摘要、经验、原始证据、外部知识、向量嵌入
    - Memory Structure:怎么组织?时序 flat、层级 hierarchy、图 graph、向量检索
    - Memory Processing:怎么维护?Create / Read / Update / Delete,也就是写、读、更新、删除

    典型例子:Mem0、G-Memory、Generative Agents、MemoryBank、Zep。
    核心价值是让 Agent 从“跑一次忘一次”变成“越用越聪明”。

    ### 3. Tool Governance

    朴素理解:让 Agent 学会选工具、修工具、甚至自己造新工具。

    论文把这个方向称为 Tool Governance Metacognition,包含三种能力:

    - Dynamic Tool Routing:从越来越多的工具中,动态选择、排序、组合工具
    - Iterative Tool Refinement:工具出错时,修改、调试、抽象成可复用技能
    - Autonomous Tool Creation:现有工具不够时,自己写新工具、安装依赖、接入系统

    典型例子:VOYAGER、Tool-Star、MCP-Flow、ToolMaker、AgentOrchestra、ATLASS。

    ### 4. Full Scaffolding

    朴素理解:让 Agent 改自己的整个程序和运行逻辑,而不只是改某一句 prompt、某条记忆或某个工具。

    这是 Scaffolding Improvement 中最深的一层,也是最接近“递归自改进”的一类。在论文里,它是:

    - 把整个 scaffold 当成可修改对象
    - 当前 Agent 自己作为“改进器”,生成对自己代码的补丁
    - 通过单元测试、回归测试、安全检查等验证后才接受修改
    - 可以同时修改 prompt、memory、tools 和 control logic

    典型例子:AlphaEvolve、ADAS、Self-Taught Optimizer、Gödel Agent、Darwin Gödel Machine、Live-SWE-Agent。

    ## 一句话总结

    分类 朴素理解
    ━━━━━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    Intrinsic Demonstrations 自己出题、自己写答案、自己练
    ────────────────────────── ─────────────────────────────────
    Intrinsic Feedback 自己给自己打分、挑毛病
    ────────────────────────── ─────────────────────────────────
    Extrinsic Experience 出去做事,靠环境判断对错
    ────────────────────────── ─────────────────────────────────
    Prompt 改给 Agent 的说明书
    ────────────────────────── ─────────────────────────────────
    Memory 改 Agent 的笔记本
    ────────────────────────── ─────────────────────────────────
    Tool 改 Agent 的工具箱,甚至造新工具
    ────────────────────────── ─────────────────────────────────
    Full Scaffolding 改 Agent 的整个程序和运行逻辑

    这些分类并不是互斥的。实际系统经常混合使用:既自己生成训练数据,又用环境反馈验证,同时改 prompt、memory 和 tools;而 full scaffolding 通常会把前面几种改法包在一起,再整体验证、回退。
  2. 1. agentcore 介绍
    2. Amazon quick : 自然语言创建agent,activity feed,
    3. takeaway
    evaluation first
    agentcore 聚焦业务
    now
    4.
  3. #人工智能
    我最近由于大量采用agent编程,现在可以并发开多个agent搞多个项目,这就对我家里的硬件提出新的要求:需要能够便捷查看多个agent的工作情况。

    原先我的屏幕配置是:一个27寸显示器,加上14寸的MacBookPro,这样合起来就是双显示器。

    我的新要求是:能够再多一屏,这样看多个agent的工作就更方便。于是,我需要从原先的27寸显示器升级到了32寸显示器,这样就能分三个屏(Mac一个,32寸显示器分两个)。这里又面临两个问题:由于显示器更宽了,导致要把眼睛和显示器的距离拉得更长才行;第二个问题是,如何快捷得给显示器分两屏。

    第一个问题,肯定是要把办工桌换成更长的桌子。根据人体工学的理论,27寸的显示器桌子长度55cm,但是到了32寸的显示器就需要到75cm了。我家的书房摆满了东西,重新腾空、拆掉已有的书桌安装一个新的书桌特别折腾。我用了一个折中的办法,电商平台上买了一个给书桌加长的板子,这个方案凑合了一点,但是it works!

    第二个问题,我原先打算买有PBP(Picture By Picture)功能的显示器,这样可以在显示器上“物理模拟”出两个显示器来。但是这个方案并不靠谱,因为分屏操作在我的场景里是非常高频的操作,如果用PBP还需要手动调整显示器的分辨率。所以我选择了“软件分屏”的方案,我采用了Rectangle开源软件),这个软件使用快捷键就能让软件的窗口缩放,非常方便。

    现在折腾完毕之后,有三个屏幕,工作起来特别方便。

    我这次折腾是很典型的:由于环境发生了变化(需要方便看多个Agent的工作),导致的配套基础设施也需要跟着变化。

    类似的,由于Agent写代码更快,导致提交代码更频繁,最近一段时间Github也是频繁宕机。
  4. 用 LLM 写代码对架构清晰和代码质量的要求其实更高,因为 LLM 不是你的脑子,他不知道现在的架构里面有哪些坑,没有那些 Context,在短上下文的情况下一个歪掉的塔只会越盖越歪。

    比如你的系统里面有一坨 legacy 导致了两条 parallel 实现,LLM 搞不清楚该在哪条上继续开发,就会变成一会在 legacy 上雕花一会去在正常流程上堆料,最后一团混乱。

    你必须得非常清楚自己的架构,如果歪了赶快扶正,尽可能多地写文档。索性 LLM 很擅长做重构(大概率比你擅长),在多次 Review 的情况下会给你一个干净的结果,而且它也大概率比你会写文档。

    所以,别用 LLM 糊屎,糊出来了屎也不是 LLM 的问题,是你的管理技术有问题。