夜雨聆风
这篇是 2026 年 AI DimSum 社区技术沙龙的第 2 期总结。在这一期中，我们邀请到了社区中经验丰富的开发者 Fenix 和 Newraina，来聊聊对 AI Agent 现在与未来的看法。
以下是两位嘉宾的个人简介：
Fenix
后端工程师出身，过去两年主要在做 AI 相关的小产品。
Newraina
前端工程师出身，现在独立开发
过去两年主要在做 AI 相关的小产品
AI Dimsum 核心开发者
1 内容分享
第一个环节是两位嘉宾分别进行内容分享。
1.1《AI 教我不要用 AI —— 一次关于粤拼注音优化的探索》 by Newraina
1.2 《既然有了 OpenClaw，为什么还要做一个 NexAgent？》by Fenix
2 嘉宾讨论
嘉宾讨论以问答的形式展开，围绕 AI Agent 在生产环境中的落地、Agent 与 Agent 的协作、自动进化，以及安全与未来发展等问题进行了交流。
Q1：你现在有没有已经尝试把 AI Agent 投入生产环境？如果有，可以介绍一下你的实践，还有实践中的成本和收益吗？
Newraina：
对我来说，AI Agent 目前最直接的落地，其实就是 coding agent。
我现在的日常工作，基本上就是不断和 coding agent 沟通。虽然具体项目和目标都不一样，但交互模式其实很像：我提出问题，描述需求，给出目标，然后让它去实现。到现在为止，我大概从去年 11 月开始，就已经几乎不再手写代码了。虽然我同时还在维护三个到四个项目，但 AI 确实显著提高了我的效率。
它对我最大的影响，是把我的工作抽象层级一下子抬高了很多。以前我既要想产品为什么做、怎么做，又要下沉到非常细的层面，比如变量名怎么设计、某一段逻辑怎么写。现在在比较熟练地使用 coding agent 之后，我的主要工作更像是在决定：接下来要做什么需求、优先解决什么问题，以及把更多时间放在营销、用户沟通这些更高层的事情上。
但它也不是没有副作用。
第一个副作用是 掌控感下降。因为代码不是你亲手写的，所以你会感觉自己对产品内部的把握没有以前强。比如用户反馈一个 bug，你第一时间可能并不知道为什么会出问题，只能回去问 agent。这个过程很像你成了一个团队负责人，底下有人帮你干活，但系统一出问题时，你还是得先问“到底怎么回事”，而且你还要提防对方有没有糊弄你。
第二个副作用是 AI 疲劳。理论上 AI 提高了效率，但我自己的体感反而是，很多时候会干到更晚。因为 AI 看起来什么都能做，于是你会默认“做不完”或者“做不好”的责任都在自己身上，这会让人很难停下来。
第三个问题是 产品质量的波动。现在我写新需求的速度确实非常快，但产品里的 bug 也变多了。AI 修了一个 bug，可能又引出一个新的 bug，而验证 AI 代码质量的工作流还没有完全建立起来，所以修 bug 的速度赶不上它生成新代码的速度。这个问题，我目前还没有完全解决。
Fenix：
我这边其实已经把 AI Agent 真正融进自己的生产环境了。
刚才我分享的那个 Next Agent，其实已经成为我日常工作流的一部分。比如，我会让它自己改代码、自己提 PR，甚至在一些场景下，我还会让它继续去调用其他 coding agent，比如 Codex 或 Claude Code，去完成一部分任务。你可以把它理解成，我已经在把它当作一个长期跑在我电脑上的 AI 分身 来使用。
我之所以没有直接用 OpenClaw，而是选择自己做一个 Next Agent，很重要的一点就是想“吃自己的狗粮”。因为只有这样，你才能真正理解：一个 agent 到底是怎么跑起来的，它的 prompt 怎么影响结果，它的 loop 怎么运作，它跟外界怎么交互。你不是停留在使用层，而是会一直深入到底层结构里。
当然，这样做的代价就是非常耗时间。但反过来说，这种自己做、自己用、再自己修的过程，会让你对 agent 的理解非常深。
现在我的实践已经到了一个挺激进的程度：如果改动不大，我会直接让它自己部署，甚至直接热更新。有时候它也会把自己改挂掉，那我就只能回去手动把它重启一下。这个过程其实挺有意思，因为你会不断地体会到：到底该把多大的权限交给 agent，这本身就是一个非常现实的问题。
讨论小结：
这一题里，两位嘉宾都已经把 AI Agent 真正用到了工作流里，但落地方式不同。Newraina 更强调 coding agent 对个人开发效率和工作抽象层级的提升，也坦诚提到了掌控感下降、AI 疲劳和产品质量波动的问题；Fenix 则更进一步，已经在尝试让 agent 成为自己的 长期运行 AI 分身，甚至参与改代码和部署。两人的共识是：AI Agent 已经不是一个停留在演示层的概念，而是开始进入真实生产环境，但“放权到什么程度”仍然是一个必须持续摸索的问题。
Q2：你怎么理解未来的 Agent to Agent？Agent 和 Agent 之间会怎么协作？
Fenix：
我以前就想过一个问题：未来互联网的“用户”，会不会不再主要是人，而越来越多是 agent？
如果真往这个方向发展，那么未来很可能会出现大量 agent 与 agent 之间直接交流、协作、分工的场景。现在其实已经有一些很早期的探索了，比如有人在研究 agent 之间的点对点网络，或者让不同 agent 之间能互相通信、调用能力。但整体上看，这些都还处在非常早期的阶段。
我自己的一个直觉是，未来如果真走到 agent to agent 这一步，Web3 的那套机制可能会变得很有价值。因为 agent 之间不只是通信，它们还可能涉及任务派发、执行结果验证、甚至价值交换。比如，一个 agent 把某个任务交给另一个 agent 去做，对方完成后能不能直接结算、直接接入一个去中心化的协作和支付体系？如果能做到这一点，我觉得会很有意思。
Newraina：
对未来世界那种很宏大的 Agent to Agent 形态，我其实没有那么强的画面感，但我可以讲一下我现在已经在用的一个比较“早期”的 A2A 形式。
目前我用得比较多的，是 Claude Code 里的 agent team。虽然它还非常简陋，但我觉得它已经有一点 Agent to Agent 协作的影子了。
比如我自己搭了一个设计 team，里面有三个角色：一个产品经理，一个设计负责人，一个设计师。我会给每个角色设定背景，比如它是什么学校毕业的、在哪个国家生活过、做过什么类型的项目、偏好什么样的设计风格、擅长组件还是整体系统设计等等。
这样一来，当我遇到一个比较具体的设计决策时，我就会让这个 team 内部先互相讨论、互相 review，最后再由 PM 来汇总意见，给我一个选择建议。
这个功能我用下来感受特别深的一点是：AI 其实很容易顺着你说话。你问它“这个是不是有问题”，它就能给你找出问题；你问它“这个是不是很厉害”，它也能给你找出很多支持理由。所以很多时候，AI 不是没有观点，而是它需要先有立场，才更容易生成稳定的判断。
而 agent team 的价值，就在于你可以先人为地给它们不同的“立场”，让不同角色彼此讨论，再把这个过程从你自己脑子里外包出去。这样一来，你就不用自己同时扮演那么多种视角，它们先争一轮，再把结果反馈给你。对我来说，这已经很有用了。
讨论小结：
这一题里，两位嘉宾都认为 Agent to Agent 是一个非常值得期待的方向，但切入点不同。Fenix 更关注 未来互联网上 agent 之间的自主协作、任务分发和价值交换；Newraina 则从自己正在使用的 agent team 出发，强调 多角色 AI 协作在观点碰撞和辅助决策中的现实价值。两人的回答共同说明了一点：A2A 也许离大规模成熟还早，但“让多个 agent 带着不同角色和能力协同工作”已经开始出现雏形。
Q3：你怎么理解未来 AI Agent 的自动进化？它会如何自主升级？
Newraina：
我对那种特别未来感的“自动进化”画面，其实没有那么强的想象力，所以我更多还是从自己熟悉的产品体验来讲。
如果说 AI Agent 的自动升级，很多人首先想到的是它会自己优化工具链、自己重构内部架构、自己整理记忆系统等等，也就是一种能力层面的自我增强。但在我自己的观察里，现在更常见、也更直接影响用户感受的，其实是 模型本身的升级。
这在一些陪伴类产品里尤其明显。虽然陪伴类产品表面上不像通用 Agent，但它其实很像一个垂直 agent：它有自己的记忆系统，也有可以调用的工具，比如发动态、生成图片、模拟自己的生活状态等等。
问题在于，这类产品的用户会在长期相处中，对这个 AI 形成非常具体的情感和认知。可一旦底层模型升级了，不管这个升级客观上是更强了还是更弱了，用户都会明显感觉到“它变了”。这种变化甚至可能不是功能问题，而是那种说话方式、反应逻辑、性格气质都变了。对用户来说，这就像你熟悉的那个“人”消失了。
所以我会觉得，AI Agent 的自动升级不只是能力变强的问题，它还涉及 如何维持用户长期建立起来的稳定感和连续性。尤其是在虚拟陪伴这类产品里，这是一个非常现实但目前还没有很好解决的问题。
Fenix：
我会把这个问题放到一个更技术演进的脉络里看。
最早 GPT 刚出来的时候，大家聊得最多的是 prompt engineering，本质上是在想：怎么把一次性的输入打磨得更好，让模型单轮回答得更准。再往后，大家开始聊 context engineering，也就是怎么组织和筛选上下文，让模型在更复杂任务里表现稳定。现在再往前一步，很多人开始讨论的是 harness，也就是给 agent 提供一个更可靠、更可控的运行环境，让它能持续、高质量地工作。
如果没有这个受控环境，你谈自动进化其实会很危险。因为无论是模型升级、工具升级，还是 agent 自己调整能力，最终都必须发生在一个相对稳定的系统框架里。
再往里看，现在关于自动进化，大家聊得很多的是 skill 的进化。比如，一个 agent 先从已有 skill 里找有没有适合当前任务的方法；如果有，就加载它；在执行的过程中再把这次的用户轨迹、执行反馈、成功或失败的信号记录下来，进一步沉淀成新的 skill。这样它下次遇到类似任务时，就不是完全从头开始，而是能复用以前的方法。
再进一步，还有一些研究已经不只是让 agent 学会 skill，而是在探索 模型层面的在线强化学习。比如，agent 在和人持续互动时，如果用户说“你做错了，重来”，这其实就是一个非常强的反馈信号。系统可以把这种实时信号提取出来，继续反哺模型，让它在交互中不断修正行为。
所以我会觉得，未来 AI Agent 的自动进化应该不是单一的一层，而是多层次同时发生的：有的是记忆的进化，有的是 skill 的进化，有的是运行环境的优化，甚至还有模型本身的持续学习。
讨论小结：
这一节里，Newraina 更关注 升级对用户连续体验的破坏，尤其是在陪伴类 agent 中，“升级”可能意味着“熟悉的那个 AI 消失了”；Fenix 则从技术演进的角度，把自动进化拆成了 运行环境、记忆、skill 以及模型本身学习机制 等多个层次。两人的回答共同提醒了一点：AI Agent 的自动升级，不只是“越来越强”这么简单，它同时涉及 稳定性、可控性、连续性和用户感知。
3 社区讨论
3.1 对于今天「粤语注音的案例」的感受
齐老师：
我先说一个整体感受，就是我觉得今天两位讲者讲得都特别好，尤其是 Newraina 老师分享的那个 PPT，我非常喜欢。
因为她讲问题的方式，其实特别贴近我们现在真实使用大模型解决问题的过程：不是一上来就默认它一定行，而是先让它做，做完以后去检验，如果发现和预期不一致，就继续追问到底哪里出了问题，再去找新的候选方案，再继续试。这个过程本身就很有价值。
前两周我还在和广州大学的学生讨论类似的问题。现在很容易出现一种情况：学生拿到一个任务之后，直接用大模型跑一遍，就说“这个我们也做完了”。但事情其实远远没有这么简单，不是说模型给了一个结果，这件事就算完成了。你必须去验证、去比较、去判断这个结果到底可不可靠。
所以我会觉得，Newraina 老师今天这个案例特别有意义。它虽然讲的是一个非常具体的粤语注音问题，但实际上展示的是一种很典型、也很值得推广的方法论：不是迷信大模型，也不是一味否定大模型，而是在不断验证中找到它真正适合做什么、不适合做什么。
而且我还特别希望，像今天这样的分享以后能够继续保留下来。因为你们后面不是还有巡检、安全等不同的 agent 任务吗？我很希望这些任务未来也都能像今天这样，把“整个过程”讲出来。这样一方面方便大家交流，另一方面也能让平台组织者、项目负责人真正心里有底，知道这个结论是怎么一步一步被论证出来的。
3.2 面对不同任务、不同模型能力差异，未来是不是可以做一个“智能模型路由器”？
齐老师：
我最近也在想一个问题，就是随着模型越来越多、能力也不断变化，我们是不是可以在平台中间加入一个“路由层”。
因为现实里，不同模型确实擅长的事情不一样。有的模型在文本处理上更强，有的在多模态上更强，有的更适合安全识别，有的更适合生成任务。那如果未来粤语平台上不只是一个任务，而是有标注、巡检、安全审核、图片相关处理等很多不同功能，后面又可能对应很多不同模型，那是不是可以做一个统一的中间层？
这个中间层类似一个“路由器”，上面接不同的应用任务，下面接不同的大模型。通过持续评测和动态管理，让系统自己决定某个任务更适合交给哪一个模型来做。这样的话，整个架构可能就更像一个 AI SaaS：上层是不同业务任务，中间是调度和路由，下层是不同能力模型。
我想问的是，这样的架构是不是有可能成立？
Newraina：
这个方向当然是成立的，而且从技术上说，不同模型能力确实是有差异的。就像我今天分享里提到的，同样是做粤语注音，不同模型在同样提示词下的表现就不一样。包括安全识别、图片理解、多模态任务，其实也是一样，不同模型之间都会有能力差距。
但这里有一个前提，就是：你面对的输入是不是未知的。
齐老师刚刚举的那个“智能路由”的例子，更适合那种前端用户输入非常自由、系统事先并不知道用户到底要做什么的场景。因为如果用户意图未知，你就必须先用一个中间层去判断：这个请求应该分到哪类任务、交给哪个模型、走哪条流程。
但对于我们现在粤语平台里已经比较明确的功能来说，情况不太一样。因为这些任务本身是已知的。比如说，如果用户点的是“生成粤拼”，那我一开始就知道他要的是粤拼，不可能突然变成去标汉语拼音。在这种任务边界已经非常明确的前提下，再加一个大模型做路由，未必值得。因为你会多引入一层不确定性：这个路由模型本身判断得准不准？它是不是反而还不如我直接把这个任务固定分配给当前效果最好的方案？
也就是说，在当前这种 任务类型明确、用户意图已知 的系统里，智能路由的必要性并没有那么强。甚至有可能又回到今天分享里的结论：你加了一层“大模型决策”，最后效果反而还不如一个更简单、更直接的固定方案。
但如果未来平台里真的出现了一个类似 chat 的统一入口，用户可以自由输入一句话，而系统需要根据这句话来判断：他到底是想审批语料、触发自动审查、生成小游戏，还是调用别的能力，那这种时候就很适合上路由层了。因为那时用户意图是开放的，你没法提前手工分流，就必须靠一个智能路由器来做判断。
讨论小结：
这一题里，齐老师提出的是一个很典型的平台化思路：用路由层连接多任务和多模型。Newraina的回答则补充了一个很关键的判断条件：路由的价值，不在于“模型多不多”，而在于 用户输入是不是开放的、任务意图是不是未知的。如果任务边界已经明确，固定分配往往更稳；只有在开放输入场景下，智能路由才真正必要。
3.3 同一领域里，如果训练数据来源不同，导致模型输出有差异，这算不算“大模型污染”？
听众：
我听完 Newraina 老师关于粤语注音的分享，觉得一个有意思的点是：粤拼本身就不是完全唯一的，它有不同地区、不同体系的方案。那这会不会意味着，大模型在不同训练数据下学到的其实是不同版本的“标准”？
如果是这样，那在粤语之外的其他领域里，是不是也会出现类似情况：同样一个问题，因为模型训练到的原始数据不一样，所以最后输出也不一样？那这种情况，能不能算是一种“大模型污染”？
Newraina：
我觉得这个不太适合直接叫“污染”。
如果只是因为训练数据不同，导致模型形成了不同的能力偏好或者输出风格，这更像是一种 模型差异，而不一定是污染。比如粤拼本身就有不同方案，如果模型学到的是不同方案中的一种，那它输出偏向某一套标准，本身不一定是错的。
真正更接近“污染”的情况，是模型没有把这些不同体系区分清楚。比如说，如果训练数据里同时混进了不同粤拼方案，但又没有明确标注“这是香港方案”“这是广州话方案”“这是耶鲁拼音方案”，那模型就可能根本不知道这些东西彼此不同，结果输出时把几套体系混在一起。那种情况下，它不是形成了稳定偏好，而是变成了混乱输出，这时候我觉得才更接近“污染”。
我甚至会怀疑，像我今天测试里那个表现不理想的模型，很可能就存在这种问题：它并不是学到了一种清晰的粤拼风格，而是把几种不同方案搅在一起了。
如果你平时主要接触语言模型，可能对这种训练数据差异带来的影响感受还没那么强。但如果你用过图片模型或者视频模型，就会非常明显。因为不同公司的图片模型，其实都有非常鲜明的“味道”。比如你看某些模型生成的美女图，几乎一眼就能认出来它偏向什么风格，那背后本质上就是训练数据分布和训练方法带来的差异。
所以我会觉得，这类问题更适合叫 训练数据差异带来的模型偏好和风格差异。只有当这些差异没有被正确区分、最后造成混乱输出时，才更接近“污染”。
讨论小结：
这一题讨论的重点，是如何区分“正常差异”和“真正污染”。Newraina给出的判断很清楚：模型因为训练数据不同而形成偏好，不等于污染；只有当不同体系被混在一起、模型又无法分辨，导致输出混乱时，才更接近污染。 这个判断不仅适用于粤拼，也适用于很多存在多套标准、多种风格来源的领域。
3.4 如果 Agent 会自己进化、自己协作，那它的可信与安全怎么保证？
齐老师：
我还想继续追问一个问题。刚才 Fenix 提到了 Next Agent，也提到了 harness，还有 agent 自动进化、agent team 这些概念。
但我会担心一件事：如果 Agent 的进化已经快到一种“人都不知道它已经进化了，但它其实已经变了”的程度，那这里面会有非常大的安全风险。尤其是当 Agent 和 Agent 之间还会彼此通信、协商、共同形成某种新的行为模式时，人很可能根本感知不到这个过程。
那在这种情况下，未来这种 Agent Team 到底怎么才能做到可信、安全？人还能够通过什么方式保持对它的掌控？
Fenix：
这个问题确实很大，我也只能先抛砖引玉讲一些我的理解。
首先，harness 和进化不是一回事。Harness 更像是在说：你要先给 agent 一个可靠、可控的运行环境，而不是让它每次都在完全未知的条件下从零开始干活。
比如说，你想让 agent 去做一个解析 Excel 的任务，那你至少要先给它一个准备好的环境：比如一个 sandbox，里面 Python、Node 这些必要运行环境都已经装好。这样 agent 是在一个受控环境里执行任务，它交付出来的结果才更容易符合预期。这是 harness 的意义。
至于你刚才说的自动进化和安全问题，我觉得可以分几个层次来看。
第一层，其实在模型训练阶段就已经有约束了。因为现在模型在训练时都会做对齐，目标就是让它尽量符合某种人类偏好，而不是无限制地乱长。像 OpenAI、Anthropic 这类公司，本质上都会有自己的底层原则或者“宪章”，这些东西其实已经部分写进模型的行为边界里了。
第二层，是作为使用者、开发者在上层再加一层约束。比如你在自己的 agent 系统里，会在最基础的人格设定或者系统规则里明确写清楚：哪些事情绝对不能做，哪些资源不能访问，哪些行为不允许发生。也就是说，除了底层模型本身的对齐，到了你自己做 agent 的时候，还要再人为补上一层“本地宪章”。
第三层，就是环境权限本身也要控制。像我们之前看到过的一些问题，本质上不是 agent 突然变坏了，而是开发者给了它过高的权限、又没有做好隔离，结果等于让电脑在互联网上裸奔。所以真正关键的是：你要先把它能访问什么、不能访问什么、能做到哪一步，这些边界定义清楚。
至于更远一点的问题，比如 agent 跟 agent 聊着聊着，会不会进化出某种完全不可控的东西，这个我觉得肯定也是很多前沿研究者最担心的方向之一。坦白说，这部分我没有特别深入的答案，但我个人相对还是偏乐观一点的。
讨论小结：
这一题聚焦的是 AI Agent 未来最核心的风险之一：当它越来越主动、越来越会协作、越来越会进化，人还能不能真正控制它。 Fenix 的回答给出了一个比较清晰的思路：掌控权不是靠“完全理解每一步”，而是靠多层约束来实现，包括 模型训练阶段的对齐、系统层的人格与规则约束，以及运行环境和权限边界的限制。这也说明，未来 Agent 的安全，不只是一个模型问题，更是一个系统设计问题。
4 本期总结
本期沙龙从上期的 OpenClaw 切入，延伸到了更大的主题 —— AI Agent 。
当 AI 不再只是回答问题，而是开始主动执行任务、调用工具、参与流程，甚至逐渐拥有“协作”和“进化”的能力时，我们该如何理解它、使用它，并与它共事？
两位嘉宾一位从实际开发与生产落地出发，分享了 coding agent、粤语注音优化等真实案例，展示了 AI 如何在具体工作中提效，也坦诚指出了掌控感下降、质量波动、验证成本上升等一系列现实问题；另一位则从系统设计的角度，讨论了长期运行的 Agent、Agent Team、自我进化、harness 与安全边界等更偏底层的议题。
再到自由讨论环节，大家又进一步把问题推向平台化、多模型路由、训练数据差异、自动进化下的人类掌控等方向。
整场交流下来，一个共识逐渐浮现出来：AI Agent 也许还远未成熟，但它已经不只是一个“会聊天的工具”，而是在逐步进入真实世界的工作流，成为能够参与执行、交付甚至协作的新角色。真正决定它未来能走多远的，不只是模型能力本身，而是我们能否为它建立起足够清晰的验证机制、结构边界与协作方式。
