Personal Agent 落地思考:主动性从哪来,又卡在哪?

简介: 本文探讨Personal Agent(PA)的“主动性”本质:它源于“目标−现状”的差距,而非单一功能。文章提出主动性分层模型(L1-L5),指出L4/L5需明确可计算目标与验收规则,并强调失败代价决定执行权限。QCA平台为此提供身份、记忆、事件触发与安全执行等基础设施。

personal agent.png


上一篇《Qoder Cloud Agents 助力开发者走进 Personal Agent 时代》介绍了 QCA 如何把身份、记忆、IM 渠道、定时任务与云端执行连接成一套开发底座。这一篇分享 Qoder 在产品落地的一些思考:当 Agent 可以持续工作后,它该在什么事上主动,又应该主动到哪一步?


01.png


现象:大家说的"更主动",到底是什么


这一轮 Personal Agent 产品出来以后,讨论里出现最多的一个词是“更主动了”:它会自己来找你,会记得你上周随口说过的事,会在你没开口的时候替你把事情往前推。看起来更主动里,但“主动”不是一个单独的功能。拆开看,它是这三件事组合出来的外显效果。


5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd53041acd314fe4c9ceee226e22e0b1fa84ae6802cf5c9b6f984453fb1432e324361bc0cc4ed23f0d29484fb4c8ed7016461c.png

图 1 · 三要素组合出“更主动”


产品

更突出的能力

同时覆盖了什么

对主动性的意义

Cue

独立身份

Agent 拥有自己的邮箱、电话、钱包和电脑;可连接邮箱、日历和消息服务,自动化可按时间或受支持的事件与条件启动,并具有跨会话记忆

让 Agent 在用户离线后仍有身份、有触发、有上下文地继续工作

Muse

跨应用执行

通过连接器和独立安全环境进入邮件、业务系统与交易流程;在状态变化或需要授权时返回找用户,也会记住长期上下文

把外部系统变化真正接入“发现—判断—执行”循环

Today

结构化长期记忆

连接日历、邮件、笔记、文件和健康数据;以晨间简报、晚间收尾和变化感知主动整理,并在确认后跨应用执行

把分散信号解释成与个人目标相关的下一步


三件事缺一件,主动性都有缺失:

  • 只有身份、没有数据源,Agent 在场却无事可做。
  • 只有数据源、没有记忆,推送什么都像群发通知。
  • 只有记忆、没有身份,Agent 想到了也只能等你下次打开对话框。


有了身份,数据源的变化本身就是事件


这里有一个容易被忽略的点:一旦 Agent 有了独立身份,数据源的变化天然就是事件源。


拿 git 举例。Agent 可以定时去读仓库状态,这是一种获取变化的方式。push、merge 本身也是事件,在 DevOps 里,它们就是各条 pipeline 的触发时机。人不在的时候,这些事件照样发生;Agent 有了自己的账号和权限,就能像流水线一样被它们唤醒。


所以 Agent 判断"什么时候该动",时机可以有两种来源:

时机来源

方式

例子

定时去读

轮询,按节奏检查状态

每晚扫一遍今天的消息和文档

变化即事件

订阅,数据一变就被唤醒

PR 被 merge、群里有人 @我、日程被改


到这里,"Agent 能不能主动"的问题基本解决了。但还有一个更关键的问题没回答:它该在什么事上主动?


02.png


本质:主动性来自"目标 − 现状"


回到最朴素的问题:人为什么会主动去做一件事?


因为心里有个目标,眼前的状态和目标之间有差距。差距让人意识到"这里有个问题",问题再被拆成要做的任务。


5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd530480ffc8fe9ce306e3c75e15e3b0841caabdc4615360154e133dfa407e500eb82deb52921ec2e860004fb4c8ed7016461c.png

图 2 · 目标 − 现状 = 差距 → 问题 → 任务


Agent 也一样。没有目标,就没有差距;没有差距,主动就只是在刷存在感。


这件事在任务级 Agent 上其实已经发生了


今天的 Coding Agent 和各类通用任务 Agent 都在做这件事:用户给一个 goal,Agent 跑一个 loop,执行、检查,再对照 outcome 判断是否完成。中间缺什么就补什么,这本身就是"按差距行动"。


PA 并没有发明新机制。它做的是把任务级的 goal / outcome 在两个方向上放大:

5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd5304b687d35ad1ee716cdcf61f6065fe003798918887c1eb97279943651403d09dabbbf2bcb5024fe5804fb4c8ed7016461c.png

图 3 · 从任务级目标到 PA 长期目标


维度

任务级 Agent

PA(长期目标)

范围

一次任务

项目、里程碑,甚至一个人的目标(比如"成为某个领域的专家")

周期

一次会话、一个 loop 内结束

跨越多次任务,像 loop 里的暂停和继续,只是拉得更长

用户在不在场

基本全程在

大部分时间不在

问题从哪来

用户直接给

Agent 从差距里算出来

授权怎么给

一次任务一次授权

按子任务逐个授权


放大之后,有三件事随之改变


① 主动性从加分项变成了刚需。 任务级 Agent 不主动也能交付,因为用户就在旁边,随时会推它一下。长期目标下,用户大部分时间不在场。Agent 不自己跟踪、不自己发现问题,目标就会停在原地。主动性是被长期目标逼出来的。


② 授权跟着子任务走,不跟着目标走。 我给了 Agent 一个"把这个里程碑推到上线"的目标,不等于授权它替我给所有人发消息,也不等于授权它改线上配置。目标只说明了方向,每个子任务的风险都不一样,授权只能一个个给。


③ 周期越长,越需要持续对齐目标。 一次任务里,目标在开头说清楚,基本不会变。几周的周期里,目标本身会漂:优先级变了,上游决策变了,我自己的想法变了。Agent 如果拿着三周前的理解一路往前推,就是在"目标已经错位,却还在用力推进"。这是长期主动最危险的失败方式。


03.png


主动性是分层的


既然主动性来自"差距 → 问题",分层的标准就很自然:这个问题是谁定义的?可以分两根轴来看


横轴:谁定义问题

层级

名称

谁定义问题

典型例子

这一层能解决什么

L1

指令

用户

"帮我把这份文档总结一下"

我说了,你去做

L2

时间

用户预设规则,Agent 判断时机

每天早上九点汇总昨天的消息

重复的事不用每次都开口

L3

外部事件

用户预设条件,Agent 感知事件

PR 合入后自动跑检查;群里有人 @我 时先接一下

响应及时,人不在也不漏

L4

持续目标

用户给目标,Agent 计算差距、定义问题

给定里程碑,Agent 自己发现"这个依赖还没人认领"

我没想到、但该做的事

L5

自生目标

Agent 推断目标,自发生成日程和任务

Agent 从我的聊天里推断"她最近想往某个方向转",开始替我安排

我自己还没意识到的目标

5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd5304af357f383264fb3251830b9bdde09e42e67f4c77282e82f927aa10b989b056e46f29bd7b358241b14fb4c8ed7016461c.png

图 4 · 横轴:谁定义问题(L1–L5)


L3 到 L4 是质变。


L1 到 L3,不管看起来多智能,问题都是用户定义的:L2 的时间规则是用户定的,L3 的触发条件也是用户定的,Agent 只是在合适的时机执行。


到了 L4,用户只给目标,"现在缺什么、该补什么"由 Agent 自己算出来。L4 有一个前提:差距必须是可计算的。目标是清晰的,要么能量化,要么有可检查的状态。


L5 本身是 Agent 自己推断目标;L4 的目标如果说不清,就会实际上变成 L5。

目标写法

差距能不能算

"10 月底前上线三个功能,每个都过验收"

能:有数量、有截止时间、有状态

"知识库要覆盖某领域的这 8 个核心概念,每个都有一手来源"

能:有清单、有检查标准

"让团队更高效"

不能:Agent 只能猜,于是滑向 L5


纵轴:做到哪一步


横轴回答"问题从哪来",但没回答"Agent 能做到哪一步"。同样是 L4,"提醒你某个依赖没人认领"和"直接替你在群里认领",完全是两件事。


所以还需要第二根轴:

5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd5304f5204052d856ad392387c138b7ad0e09b677890742fe5789e5749b45f80fa69337e207457ea2cddf4fb4c8ed7016461c.png

图 5 · 纵轴:做到哪一步


档位

Agent 做到哪

用户需要做什么

告知

告诉你发生了什么

自己判断、自己做

建议

告诉你该做什么

自己做

起草待确认

把要做的东西准备好

看一眼,点确认

执行(可逆)

直接做,做错了能撤回

事后抽查

执行(不可逆 / 对外)

直接做,影响别人或无法撤回

事前就得信任它


两根轴是独立的。一个 L5 的 Agent 可以只停在"告知",一个 L3 的 Agent 也可以直接对外执行。讨论 PA 能做到什么程度时,必须同时说清楚它在两根轴上的位置。


04.png


Personal Agent实践与重新认识


我给自己搭了一个 PA,叫 Daisy。它有几个常驻的 loop:

  • 每日收敛 loop:每晚 20:00 扫一遍当天的会话、钉钉群、关键私聊和文档,产出两份东西。一份是待办(todo),另一份是"今天涉猎到、可能值得沉淀的话题"(discover)。
  • 自动回复 loop:白名单群里有人 @我 时,按规则先替我回复。


把它们放到两根轴上:

纵轴 \ 横轴

L1 指令

L2 时间

L3 外部事件

L4 持续目标

L5 自生目标

执行(不可逆 / 对外)

● 自动回复

执行(可逆)

起草待确认

建议

● todo

告知

● discover


横向看,它已经走到了 L4、L5:todo 是对照我的工作目标算出来的差距,discover 是它推断"我可能关心什么"。


纵向看,todo 和 discover 几乎都停在最底下两格。


数据很诚实


从 07-01 起,每日 loop 一共产出 276 条 todo,其中 138 条 被标为完成。这 138 条里有 126 条,是我在 08-13 的一次会话里集中手动核销的。loop 自己执行、关闭的:0 条。


它每天都在"发现问题",但从来没有"解决问题"。所有的执行和收口,最后都回到了我身上。


是太谨慎了吗?


发现不是。看同一个 PA 里的自动回复 loop:


它直接在钉钉群里替我回复同事。这是对外、不可逆的动作,回出去就收不回来,风险比关掉一条 todo 大得多。可这件事我放心交给它,因为规则全是我自己定的:

规则

作用

只回白名单群

圈定影响范围

话题黑名单

敏感话题一律不碰

我本人已经在处理就跳过

不和我抢话

超过 30 分钟的消息不回

不在过时的语境里发言

只有图片、没有文字时走兜底话术

不对看不懂的内容瞎答


问题是我定义的,边界是我画的,出了事责任在我。所以我敢放。


而 to do 是 Agent 自己算出来的问题。它判断"这件事该做",可如果它算错了,替我做错了,这个后果该谁来担?这个问题没有答案之前,我只会让它停在"建议"。


升仓:同一件事,可以从 L5 走到 L4


Discover 是个更有意思的例子。它一共扫出了 80 多个话题,我没有照着清单直接把它们沉淀进知识库。


但我并不是不沉淀。我的方式是:觉得某个话题值得,就接着和 Agent 聊,聊到满意、理解透了,再让它整理进知识库。清单里没处理的那些,一部分是我没时间,或者懒了;另一部分是我担心自动生成的内容直接进库,质量不够高。


换个设定,情况就不一样了。如果在 PA 场景里我明确说了"我要成为某个领域的专家",同时给出清楚的入库规则:

  • 知识架构清晰,能挂到已有的概念体系里;
  • 来源扎实,优先官方文档和一手资料;
  • 和库里已有的结论不冲突,冲突就标出来。


那么在风险可控的前提下,有一部分入库是可以让 Agent 自己完成的。


5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd5304fed5328b0072259a6ac80792206bc7d3ef625d8a0c360124147ddfcd4bff85ab5b993a20be7e4ad24fb4c8ed7016461c.png

图 6 · 同一件事从 L5 走到 L4


这一步变化里,Agent 的能力没有变,变的是我交给它的东西:一个可计算的目标,和一套可检查的验收规则。


05.png


哪些适合直接交给 Agent 主动?看失败代价


一件事能不能交给 Agent 执行,跟它在第几层关系不大,跟个人谨不谨慎也关系不大。真正起作用的是两个问题:


问题是谁定义的? 这决定了出错时的责任归属。


失败代价有多大? 拆开看是三件事:能不能撤回,影响到谁,结果能不能验证。


按这两个问题,可以把待办分成五档。每档举一个真实的例子:

档位

判断标准

两轴位置

例子

直接执行

只影响自己,可逆,结果可验证

任意层 × 执行(可逆)

检查新建的工作项是否已经加进迭代

按规则执行

问题和边界由用户预先定义

L3 × 执行(对外)

群里有人问"计费公告发了没",按规则直接回复

有目标和验收时部分执行

目标可计算,验收规则明确

L4 × 部分执行

在"成为某领域专家"的目标和入库规则下,把合格的话题沉淀进知识库

起草待确认

涉及对他人的承诺

L4 × 起草待确认

答应别人第二天上午发修改后的 PPT:Agent 可以先改好,发送由我来

只提醒

不可逆,影响客户或业务,结果无法事先验证

L4 / L5 × 告知

已经公布的 API 语义该怎么定(原则上已公布的 API 不得单方面变更)


把它画成一张图会更直观:


5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd53046db42c051543640f9ce7d3fd11201d5fe8944e262e19c50c7f97847526b68726c24be9ee512819304fb4c8ed7016461c.png

图 7 · 能不能交给 Agent 执行


左下角最适合直接执行:问题是我定的,做错了代价也小。越往右上走,越需要人在关键节点上把关。


06.png


主动性的上限在哪?杠杆是什么?


回到分层。L1 到 L3 的执行,今天已经能比较放心地交出去:问题是用户定义的,边界是用户画的,Agent 做的是"按规则执行"。真正卡住的,是 L4 的执行和 L5 的一切。


L4:Agent 定义了问题,责任却还在人身上


L4 的问题是 Agent 算出来的。算对了,它替我省了事;算错了,后果还是我担。只要这个不对称存在,人就会本能地把 L4 留在"建议"。


长周期还会让情况更糟。目标在几周里会漂,Agent 在用户不在场时拿着旧目标往前推,差距算得越认真,偏得越远。所以 L4 想往上走,除了初始的目标,还需要持续对齐的机制:在关键节点重新确认"目标还是这个吗"。


L5:在 L4 的风险上,再叠一层"目标猜错"


L5 连目标都是 Agent 推断出来的,于是出现了第二个误差来源:

  • L4 的风险:目标对,差距算错了。
  • L5 的风险:目标本身就猜错了,后面的差距、问题、任务全部跟着错。


这不是假设。据媒体报道,Meta Muse 的系统指令里就要求它去推断用户的目标,包括那些用户"没有说出口"的目标;为了做到这一点,它会读取聊天、消息、邮件和已连接的应用,这也引发了不小的隐私争议[5]。推断"没说出口的目标",能力上做得到,但用户愿不愿意被这样理解是另一回事。所以至少在今天,L5 更适合停在"告知":告诉我你观察到了什么,由我来决定这是不是我的目标。


杠杆:把目标和验收规则说清楚


回看前面所有的例子,能让一件事往上走的只有一件事:


5eecdaf48460cde546f9ee1b0ce33af55fbabd84c68775d575b8339e1c4c24831b75b38faadcd24bec177c308ebd530457ee547ba95ab896d373dac68586f8a10b5a588c3ea3562cd25b929641601883cd21ce1558a6860e4fb4c8ed7016461c.png

图 8 · 杠杆:把目标和验收规则说清楚


  • 说清目标,Agent 就不用猜,L5 变成 L4。
  • 说清验收规则,"做没做对"就能被检查,L4 的一部分变成了"按规则执行",问题定义权和责任也重新回到用户手里。


升仓就是这么走上去的:从"猜我关心什么",到"对照专家目标算差距",再到"符合规则的直接入库"。


所以,PA 的主动性能放大到什么程度,最终不只取决于 Agent 多聪明,也取决于人愿意把目标和规则说到多清楚。Agent 负责把差距算准、把事情推进;人负责把方向和底线说清楚,并在目标漂移时及时校准。


主动性的上限,是人与 Agent 之间能显式对齐的那部分目标。


用 Qoder Cloud Agents 把这套思考做成 Personal Agent


这套分层不只是在讨论 Agent 的聪明程度,也在反过来定义 PA 产品需要怎样的基础设施:稳定的身份与记忆让目标跨会话持续,Channel 与 Schedule 提供事件和时机,云端执行环境让行动在用户离线时继续;权限、确认和运行记录,则用来承接不同执行档位的风险。


如果你也想把长期目标、个人上下文和持续执行做成真正可用的 Personal Agent,可以从这里开始:https://qoder.com/zh/cloud-agents

目录
相关文章
|
2天前
|
人工智能 自然语言处理 API
Qoder Cloud Agents 助力开发者走进Personal Agent 时代
2026年下半年,Personal Agent成为AI新焦点:从问答、任务执行迈向持续交付。OpenAI Dots与Meta Muse均支持跨渠道、带记忆、可自主推进的长期协作。Qoder Cloud Agents(QCA)提供全托管平台,集成身份、记忆、IM接入、定时任务等能力,助开发者分钟级构建商业级Personal Agent。
77 0
|
16天前
|
人工智能 安全 IDE
Qoder 产品负责人张燎原:把 Agentic Coding 装进组织,Qoder助力企业向 AI Native 组织的进化
9月22日云栖大会,阿里ATH事业群Qoder负责人张燎原带来《把Agentic Coding装进组织》主题演讲。Qoder由通义灵码升级而来,已服务超800万开发者,提出“Agentic Coding Platform for Everyone”新定位,聚焦交互简化、人机协同与企业落地,助力企业迈向AI Native组织进化。
219 2
|
4天前
|
人工智能 开发者
Qoder Fast 上线:3 秒响应,还更省 Credits
Qoder 推出 Fast 模式:首次响应仅需3秒,全链路优化模型、Agent 与网络层,兼顾速度、质量与成本。适用于补代码、解 Bug、写攻略等日常任务,响应快如“即时”,效率跃升,专注力不被等待打断。
100 0
|
2月前
|
缓存 JavaScript Shell
DeepSeek Harness 终于来了:开源,一切皆插件
DeepSeek Harness 开源首夜我装好了。本文给四种下载方式、四模式区别、插件生态实测,以及一段 99% 缓存命中率的真实账单
DeepSeek Harness 终于来了:开源,一切皆插件
|
缓存 负载均衡 监控
【微服务】一文读懂网关概念+Nginx正反向代理+负载均衡+Spring Cloud Gateway(多栗子)
不知道什么是网关?正向代理?反向代理?负载均衡?负载均衡策略?Nginx和Gateway的区别?假如这些你都不知道,没关系,本文举了大量通俗易懂的例子来阐述了这些概念,保证小白也能看懂,并且最后还提到了gateway的一些配置。
13194 4
【微服务】一文读懂网关概念+Nginx正反向代理+负载均衡+Spring Cloud Gateway(多栗子)
|
2月前
|
人工智能 API 开发工具
DeepSeek Harness :当"一切皆插件"成为 Agent 的新底座
DeepSeek Harness(dsh)是DeepSeek开源的Agent执行底座,以MIT协议发布。它提出“Agent = Model + Harness”理念,采用Cordis内核与“一切皆插件”架构,支持模型、工具、沙箱等全组件热插拔。可接入多模型(含OpenAI/Claude),提供标准、PTC、极简、创造四种运行模式,并内置轨迹追踪与安全沙箱。
1396 1
|
1月前
|
人工智能 IDE 开发工具
全新 Qoder 线上发布会,今晚 19:00 不见不散!
9月1日19:00,Qoder线上发布会直播!聚焦全新 Qoder,产品、研发、设计三位成员深度解读,助你厘清 Qoder IDE与新 Qoder 的适用场景。锁定视频号「Qoder.ai」
241 1
|
2月前
|
弹性计算 JSON 自然语言处理
阿里云 Workbench CLI 上架 Qoder 插件市场,不用 SSH 也能操作 ECS
阿里云 Workbench CLI 上线 Qoder IDE,让 AI Agent 用自然语言直接操作 ECS:查实例、执行命令、传文件、看日志、部署服务——无需公网 IP、免 SSH 配置、不记复杂命令,安全高效,开箱即用。
290 0
|
2月前
|
人工智能 数据可视化 安全
Qoderian 来了:让 Qoder CLI 住进你的 Obsidian 知识库
Qoderian 是一款开源 Obsidian 插件,让 Qoder CLI 直接在知识库内运行,无需切终端。支持网页剪藏自动提炼、归类总结、生成思维导图与手绘风格流程图(配合 Excalidraw),大幅提升信息整理效率。MIT 协议,免费易用。
518 0

热门文章

最新文章