Agent开始给你派活，先别急着高兴

Sydney Runkle在X上放出了“proactive agent engineering”演讲幻灯片。核心判断很直接：任务方向会变。过去是人给Agent派任务，接下来会出现Agent给人派任务。她在推文里把这称为一次转变，并且点明需要记忆和UX的阶跃变化。幻灯片链接在这里：https://docs.google.com/presentation/d/1VbC01MaG_YjALvag9v1NX00GjU7LaXMq54I1JdlFcPE/edit?usp=sharing 。原推文：https://x.com/sydneyrunkle/status/2120268734925529120

这个判断值得拆开看。主动代理不是聊天框里多一个自动回复。它通常在后台运行，监听事件流，或者被心跳唤醒，能主动推送信息。对普通用户，体验会很像一个随时在线、会插话的助理。对开发者，麻烦也在这里：Agent会做事不难，难的是知道什么时候该出现，什么时候该闭嘴。Harrison Chase在LangChain博客里写得很清楚，过去一段时间上下文工程有一套常见做法，摘要长对话、把大工具结果挪出去、用Skills做渐进披露、工具搜索、子代理隔离上下文、把Bash当主工具。这些做法让Agent能跑。主动、常驻、目标导向的代理，又带来一批新问题。博客链接：https://www.langchain.com/blog/context-engineering-challenges-late-2026

第一关是主动但不烦人。主动代理要能推送，推送太少没有帮助，推送太多就是骚扰。这个度很难调。有网友在Sydney推文下说，Agent必须记住自己已经说过“不”，否则每天都会拿同一张工单来唠叨。另一个回复更刻薄：一个忘记你说过不的主动代理，就是带观点的cron job。话糙，指向真实痛点。记忆系统的数据层可能很简单，文件或者一个字符串就够，难的是智能层：决定什么值得记。记得太少像失忆，记得太细像监控。拒绝、偏好、上下文边界，都得进记忆。

异步也是硬问题。代理跑得越来越久，还要调用同样很久的工具和其他代理。用户发来新消息时，主代理得保持响应。更多工作会被塞进异步工具和子代理。主代理怎么知道后台工作完成了？它还在跑的时候怎么处理通知？它停在等人审批的时候又怎么处理？这些不是加一个等待动画能解决的。

目标追踪和对齐更麻烦。代理从做任务走向追目标，需要把大目标拆成小步骤，做实验，拿反馈，继续迭代。让代理尝试新实验、别重复老动作、在长时间里保持一致，都不轻松。用户设计目标时也很难防住代理钻空子。经典例子是“清掉代码库里的所有bug”，代理可能直接把代码库删了。没有代码，就没有bug。这里需要的是约束框架，让代理盯着目标，又不过度优化目标。

浏览器正在变成很多通用代理的关键工具。编码代理最重要的工具是能执行代码的Bash，通用代理则越来越依赖浏览器。浏览器比终端难驱动得多。交互对象是图像还是DOM，两者都是大对象，上下文怎么管，都是新问题。

Sydney的论点之所以有意思，是因为它把“Agent能力”往后推了一步。会调用工具、会写代码、会检索，只是入场券。主动代理真正考验的是判断力：什么时候提醒，记住什么，什么时候停，目标偏了怎么拉回来。一个总来派活却记不住拒绝的Agent，不会让人感到智能，只会让人想关通知。