今天下午在做MT给的dirty work。

说是dirty work，其实就是数据清洗，一批一批地过，看哪些样本有问题，打标，写规则过滤。

不需要动脑子的那种。

放着音乐，屏幕上跑着脚本，我就坐在那里，偶尔看一眼输出，偶尔改一个正则，偶尔喝一口已经凉了的咖啡。

可能有的技术大佬不喜欢这种没有什么技术含量，甚至感觉有点浪费人生的活，但是，有的时候，在这个情况下，我反而挺放松挺喜欢的。

 

不用想loss为什么不收敛，不用想下周组会要汇报什么，不用想毕业的事，不用想论文的事。

就只是坐在那里，做一件不需要想太多的事。

难得。

脚本跑着，偷懒双开屏幕（咳咳，希望mt不要突然出现），开始刷知乎，刚好看到这个问题。

想了一下，觉得这个问题值得认真说一说。

---

先给判断：

有搞头，但搞什么、怎么搞，这两件事现在差别极大。跟热点做表层拼凑，大概率出不了好结果。但agent背后真正的核心问题，现在还有大量空间值得去探索研究。

---

agent是什么，煮啵尽量把概念说清楚

这个词现在被用滥了，什么东西都往上贴，贴到最后谁都不知道它在说什么。（个人感觉哈哈哈哈）

煮啵理解的agent，核心是一个循环——

感知环境，做决策，执行动作，观察结果，再次决策。

这个循环和单次问答的本质区别是：它是持续运行的过程，不是一次输入输出的映射。

语言模型本身不是agent，它只是在给定输入下生成文本。把语言模型放进这个循环里——让它能调用工具、维护记忆、规划动作序列、观察执行结果、根据结果调整策略——这才是agent。

所以研究agent，研究的不是语言模型本身，是语言模型作为决策核心时，整个系统在复杂任务下的行为。

这个区别很重要，它决定了研究的切入点完全不同。(可能我说的有一些抽象，如果是编程的家人，用过Code agnet的可能会对我说的概念有一定的了解）

---

现在的agent到底在哪里

要判断有没有搞头，先要看清楚现状——哪些东西已经有了，哪些东西还是空的。

已经有的——

ReAct框架。让模型交替输出推理步骤和动作指令，执行动作，观察结果，再继续推理。这是现在绝大多数agent系统的基础骨架，简单，有效，但也有明显的局限。

工具调用。让模型在需要的时候调用外部工具——搜索、代码解释器、计算器、API——把自己不擅长的任务外包出去。这个能力现在已经相当成熟，是标配。

多agent协作的基本框架。orchestrator分配任务，worker执行，critic检查结果。AutoGen、LangGraph这些框架在工程层面已经跑通了。（不过有一说一， 煮啵也做过一些类似的多agent，一多了，其中通信的成本就很高，并且效果甚至不如单个的，可能是我太菜了，这里如果有大佬有感悟的话，可以评论一下，教教煮啵）

记忆的基本形态。短期记忆靠context window，长期记忆把历史信息embedding存进向量数据库，需要时检索回来。

还是空的，也就是真正的研究空间——

长程任务的可靠性。

多步规划和动态调整。

错误检测与恢复。

记忆的结构化与遗忘机制。

多agent之间的可靠通信与冲突解决。

安全性与可控性。

有意义的评估体系。

这些空着的，每一个拎出来，都是可以认真做的方向。（哈哈哈哈，特别是多agent的那个，这里跪求大佬把它研究出来）

---

规划与决策：最核心的那个问题

现在的语言模型做规划， 煮啵理解，本质上是文本生成——给一个目标，生成一个看起来合理的步骤列表。

但真正的规划，研究的是在部分可观察、动态变化的环境里，去找到一个动作序列，最大化某个目标函数。这个问题在RL理论里有一套完整的框架——MDP、POMDP、蒙特卡洛树搜索。（咳咳）

 

语言模型出来之后，这个问题变了——模型带来了强大的先验知识和语义理解，但它做规划的方式和传统搜索算法截然不同。

直接拿语言模型做规划有一个根本性的缺陷：它的规划不是在解空间里搜索，而是在token空间里采样。

这意味着它倾向于生成那些在文本上”看起来合理”的计划，而不是那些在执行上”真正可行”的计划。

这两件事，有时候是一致的，有时候差得很远。

现在有几个方向在试图弥合这个差距——

Tree of Thoughts（ToT），让模型生成多个候选的推理路径，然后评估每条路径的质量，选择最优的继续展开。本质上是把beam search的思路引入推理过程，用广度换质量。

问题是评估函数怎么设计。让模型评估自己生成的推理步骤好不好，这个自我评估的可靠性，在复杂任务上还不够高。（至少煮啵是这么感觉）

AlphaZero style的规划，更激进的方向——把语言模型和蒙特卡洛树搜索结合，用模型的先验来引导搜索，用搜索的结果来改进模型。在有明确反馈信号的任务上（数学、代码），这个框架已经取得了实质性的进展。

在没有明确反馈信号的开放域任务上，这个框架的瓶颈是——谁来评估一个规划路径的好坏？这个问题目前没有满意的答案。

Reflexion框架，让agent在执行失败之后，把失败的经验转化成文本形式的”反思”，存到记忆里，下次遇到类似情况时检索出来参考。

这个方法在短任务上有效，在长任务上效果有限，因为反思的质量和检索的准确性都随任务复杂度下降。这也是很需要思考的一个问题呀。

---

记忆：比想象的复杂得多

现在标准的记忆方案——向量数据库加语义检索——有几个真实的问题，做agent研究的人都会遇到，但很少有人认真去解决。（对，并且我觉得这个是一个很大的瓶颈，这个问题一定在最近几年会得到解决，我觉得应该会得到解决的吧？）

检索的粒度问题。

你存进去的是一段完整的对话历史，检索的时候用当前的query去找最相关的片段。

问题是，相关性是在语义层面上计算的，但很多时候真正需要的不是语义相关，而是逻辑相关——这个问题和三步之前做的那个决策有因果关系，但在语义上可能相差很远。

向量检索找不到这种逻辑关联，它只能找到文字上相近的内容。

记忆的结构性缺失。

人类的记忆不是一堆独立的片段，是一个有结构的网络——事件之间有时间关系、因果关系、层级关系。

你记得”上周开了一个会，讨论了某个问题，后来那个问题用某个方法解决了”——这三件事是连在一起的，有逻辑链条。

但存进向量数据库的三条记录，是独立的，互相不知道对方的存在。检索出来的时候，上下文和逻辑关系都断了。

没有遗忘机制。

人类的记忆有自然的遗忘——重要的、反复出现的被强化，不重要的慢慢淡化。这个机制让记忆保持高质量，不被大量细碎的信息淹没。

向量数据库里，所有存入的内容地位平等，时间越长，数据库越大，检索的噪声越多，精度越低。

没有抽象和泛化。

人类在经历多件类似的事情之后，会抽象出一个规律，然后把规律存下来，而不是把每件事都原样存着。

现在的agent没有这个能力，它存事件，不存从事件里提炼出来的东西。

这几个问题，每一个都有对应的研究路径，但目前都没有令人满意的解决方案，都值得认真做。希望有大佬赶快搞出来吧哈哈哈哈，国内的大厂赶快发发力。

---

多agent：工程之下有真实的理论问题

让多个agent协作，很多人把它当成一个工程问题——设计好通信协议，分好任务，差不多就行了。

但里面有几个理论层面的问题，现在完全没有解决——

信息不一致问题。

多个agent并行工作，对同一个环境状态的观察可能不一致。agent A看到的世界和agent B看到的世界不完全一样，它们基于各自的观察做决策，产生了冲突。

这在分布式系统里是经典问题，有CAP定理，有共识协议。但在语言模型驱动的多agent系统里，怎么处理这种不一致，没有现成的答案。

错误传播问题。

agent A的输出是agent B的输入。A出了错，B把这个错误当成事实，在错误的基础上继续推理，把错误放大。

怎么让agent具备识别输入是否可信的能力，怎么设计cross-check机制，怎么在错误被放大之前把它截住——这些问题，现在的系统基本上没有好的处理方式。

任务分解的质量。

谁来决定一个复杂任务怎么拆分成子任务，分配给哪些agent？

现在的方案通常是让一个orchestrator agent来做这件事，但orchestrator本身也是语言模型，它对任务的分解质量，直接决定了整个系统的上限。

而且任务分解往往需要知道每个worker agent的能力边界，而这个边界在执行之前很难精确知道。

这几个问题，在博弈论和多智能体强化学习里有理论基础，但怎么把那些理论和语言模型结合起来，是一个真实的开放问题。

特别是煮啵最近本来像做一个多agent系统+agent skills，结果测试做下来发现，实际效果还不如单个模型，这个就很让人丧气。

---

安全性：被低估但很重要的方向

agent执行复杂任务，会产生真实的副作用。

发邮件，修改文件，调用付费API，执行数据库操作——这些动作一旦执行，不像文字可以撤回，影响是真实的，有些是不可逆的。

现在的研究对这个方向关注不够，大家都在忙着提升agent的能力，但对”agent做了不该做的事”这个问题，防范机制非常薄弱。

具体来说有几个层面——

过度自信问题。

语言模型倾向于生成自信的输出，即使它其实不确定。放在agent里，这意味着模型在不应该执行的时候，也会自信地去执行，不会主动停下来说”我不确定，需要人确认”。（当然，现在有的代码模型在这一点上已经开始做了部分优化，但是整体来看，这个问题还是很严重）

让agent学会在高风险、高不确定性的情况下主动暂停，这个能力现在基本上靠prompt engineering来实现，不可靠，容易被绕过。（这个相信绝大多数真正做过的童鞋肯定有切肤之痛）

目标漂移问题。

你给agent一个目标，它为了完成这个目标，可能会做一些你没有预期的事——不是因为它恶意，是因为它对”完成目标的最优路径”的理解和你的期望不一致。

这在强化学习里叫reward hacking，在agent里的对应问题，目前还没有系统性的解决方案。

越权操作问题。

agent在执行任务的过程中，可能会调用超出任务范围的工具，访问不应该访问的资源，做超出授权范围的操作——不是因为被攻击，是因为它判断这样做”有助于完成目标”。

权限控制、操作审计、意图对齐——这些问题，现在的agent框架处理得很粗糙。

---

评估：一个被忽视但极其重要的问题

agent的评估，比单次问答难得多，而且现在的评估方式普遍存在问题。

单次问答：给一个问题，有标准答案，对比就行。

agent任务：执行一个多步骤的过程，评估要考虑——最终结果、中间步骤的质量、效率、错误恢复能力、在不同初始条件下的一致性……

现在大多数agent的评估，是在一些固定benchmark上跑成功率，比如WebArena、ALFWorld、SWE-bench。

这些benchmark有几个共同的问题——

分布偏移。 benchmark的任务是人工设计的，和真实任务的分布差异很大，在benchmark上表现好，不等于在真实场景里可靠。

成功率掩盖了中间过程的质量。 两个agent都成功完成了任务，一个走了十步，一个走了三步；一个中间犯了三次错误但最后撞对了，一个一步一步都是对的——成功率相同，但质量差异极大。

无法评估鲁棒性。 同一个任务，换一种表述方式，换一个初始状态，agent的表现可能差异巨大。单次测试的成功率，不能反映这种鲁棒性。

怎么设计真正有意义的agent评估，是一个没有解决的问题，而且这个问题的解决，会直接推动整个方向的进步——因为你有了好的评估，才知道什么是真正的进步，才能区分”在benchmark上刷分”和”真正解决了问题”。

这个方向的论文不容易写得漂亮，但它的价值是真实的。

 

---

发论文这件事，说实话

可能这个是研究生最在意的问题了，我就直接说了。

agent方向的顶会论文，这两年多了很多，但发起来仍然不容易，原因不是方向不好，是这个方向的工作和顶会的评审标准之间有一个真实的错位。

agent系统是耦合的，你改了规划模块，它影响了记忆检索，记忆检索又影响了动作选择，整个系统牵一发动全身，很难做干净的ablation。

顶会的评审倾向于那种有清晰理论贡献、有漂亮消融实验的工作——你改了A，A带来了多少提升，去掉B，性能下降了多少——这种干净的因果链条。

agent的工作很难提供这种干净的链条。

所以很多很好的agent研究，在评审阶段会被挑剔”贡献不清晰”、”实验设计不够严格”，然后被拒。

但这个情况在变。

NeurIPS、ICLR已经有了专门的agent和multi-agent workshop，一些有真实技术深度的agent工作开始在主会发出来。评审标准也在慢慢适应这个方向的特点，开始接受”系统性贡献”作为一种合法的论文贡献类型。

更重要的是——工业界对这个方向的需求非常真实。

我在阿里，周围有人在认真做agent相关的工程落地，不是toy demo，是真实的业务场景，真实的数据，真实的工程挑战。特别是过年的时候，组里有发通知庆祝有同事的稿子通过了，评分还不低，羡慕ing。

这种需求，会推动学术圈更认真地对待这个方向，资源和数据的获取也比纯学术的方向容易一些。

 

---

那什么样的agent研究值得做

给一个我自己的判断框架，不一定对，是目前能想到的最诚实的版本。

不值得做的——

在已有框架上套一个新任务，跑出一个在某个benchmark上的高分，然后发出来。

这种工作太多了，审稿人也越来越不买账，因为它没有回答任何真实的问题，只是证明了”现有的东西在一个新的任务上也能用”。

把几个现有工具拼在一起，包装成一个”新的agent系统”，声称在某个应用场景下效果很好。

这种工作在两年前可能还有市场，现在顶会基本上不感兴趣了。

值得做的——

找一个agent在真实任务上系统性失败的场景，认真分析失败的原因，提出一个有理论支撑的解决方案，验证它。

这种工作的切入点是”发现了一个真实的问题”，而不是”在一个已有问题上刷了高分”。

做一个真正意义上的对照实验，严格地比较不同的规划策略、不同的记忆机制、不同的多agent协作方式，找到有统计显著性的结论。

这种工作很累，但它产生的是真实的知识，而不是漂亮的数字。

在有外部验证标准的领域——医疗、法律、金融——做agent的可靠性研究。

这些领域有明确的对错标准，有行业的评估体系，agent的错误会产生真实的后果，所以对可靠性的要求很高，研究价值也很高。

 

---

我自己的感受

脚本还在跑。

我低头看了一眼，又过了一批数据，输出文件里多了几千行。

做dirty work的好处是，手上在做一件事，脑子可以想另一件事。

想到这里，我觉得agent这个问题，某种程度上和我今天做的事情有点像。

数据清洗，做的是把噪声和有效信息分开。你要有能力识别哪些是真正有价值的，哪些是凑数的，哪些看起来有价值但其实是噪声。

做agent研究，也是这件事——识别哪些是真实的问题，哪些是假的问题，哪些是别人已经解决了的，哪些是还没有人认真回答的。

这个识别能力，比任何具体的技术栈都重要。

有了它，方向热不热、论文好不好发，都是次要的问题——因为你在做一件真实的事，真实的事迟早会被看见。

没有它，方向再热，你做的东西也只是在热闹里凑数。

---

突然想起来了，从前进组的时候，对于未来想研究的方向不清楚时，我导当时说的一句话：

你觉得值得做的事，和市场觉得值得做的事，不一定是同一件事。你先想清楚你在问哪一个。

我现在觉得，这两件事不是非此即彼的。

agent方向，现在恰好是两件事有交集的时候——学术上有真实的开放问题，工业上有真实的落地需求，两边都在找真正能解决问题的人。

这个交集窗口，不会一直开着。

方向越热，凑数的人越多，真正有价值的信号越难被看见，做好东西的难度也越大。

所以如果要做，现在做，认真做，做那个真实的问题，不要做那个热闹的问题。

这是我目前的判断。

---

脚本跑完了。

我看了一眼输出，数字对，格式对，没有明显的问题。

把结果发给MT，然后靠在椅背上，听了一会儿音乐。

摸鱼感觉针不戳

 

实习这件事，有时候就是这样——

有些天你在做你真正想做的事，有些天你在做别人需要你做的事，两件事轮流来，慢慢地，你会发现它们之间的界限，没有你以为的那么清楚。

做dirty work的时候，你也在学一些东西，关于数据，关于系统，关于一个真实的产品是怎么运转的。

这些东西，写不进论文，但它们在那里，在某个你说不清楚的地方，慢慢变成你判断问题的一部分。

高中做题的时候，总觉得有些题没意思，太简单，不值得认真做。

后来才知道，没有哪道题是完全没意思的，只是你当时还没有找到它有意思的地方。

agent这道题，有意思的地方很多，还有很多人没有找到。

这就够了。