01
随着 Personal Agent（个人智能体）产品的涌现，“更主动”成为高频讨论词。这种主动性表现为：主动触达用户、记忆历史上下文、在未获指令时推动事务进展。本质上，“主动”并非单一功能，而是由以下三个要素组合而成的外显效果。
图 1 · 三要素组合出“更主动”
三者缺一不可，否则主动性将大打折扣：
- 仅有身份而无数据源：Agent 虽在场但无事可做。
- 仅有数据源而无记忆：推送内容缺乏针对性，类似群发通知。
- 仅有记忆而无身份：Agent 虽有洞察，但需等待用户下次发起对话才能表达。
1.1 有了身份，数据源的变化本身就是事件
一个常被忽略的关键点是：一旦 Agent 拥有独立身份，数据源的变化即天然构成事件源。
以 Git 为例，Agent 既可定时轮询仓库状态，也可通过 Push、Merge 等操作直接触发事件。在 DevOps 流程中，这些操作即是 Pipeline 的触发时机。当用户不在场时，事件依然发生；若 Agent 具备独立账号与权限，便可像流水线一样被自动唤醒。
因此，Agent 判断“何时行动”的时机来源主要有两种：
至此，“Agent 能否主动”的技术问题已基本解决。但核心问题仍未回答：它应在何事上主动？
02
回归本源，人类为何会主动行动？因为心中存在目标，且当前状态与目标之间存在差距。这种差距使人意识到“存在问题”，进而将其拆解为具体任务。
图 2 · 目标 − 现状 = 差距 → 问题 → 任务
Agent 同理。若无目标，则无差距；若无差距，所谓的“主动” merely 是在刷存在感。
2.1 这件事在任务级 Agent 上其实已经发生了
当前的 Coding Agent 及通用任务型 Agent 均在践行此逻辑：用户设定目标（Goal），Agent 执行循环（Loop），通过检查最终结果（Outcome）来判断完成度。过程中缺失的部分会被自动补全，这本身就是“基于差距行动”。
Personal Agent (PA) 并未发明新机制，而是将任务级的 Goal/Outcome 在两个维度上进行了放大：
图 3 · 从任务级目标到 PA 长期目标
2.2 放大之后，有三件事随之改变
① 主动性从加分项变为刚需。任务级 Agent 即使不主动也能交付，因为用户在线可随时干预。而在长期目标下，用户大多时间不在场。若 Agent 不自行跟踪和发现问题，目标将停滞不前。主动性是被长期目标倒逼出来的。
② 授权跟随子任务，而非跟随总目标。例如，给予 Agent “推动里程碑上线”的目标，并不等同于授权其向所有人发消息或修改线上配置。总目标仅指明方向，每个子任务风险各异，授权必须逐项赋予。
③ 周期越长，越需持续对齐目标。短期任务中，目标一经确立基本不变。但在长达数周的周期内，优先级、上游决策及个人想法均可能变化。若 Agent 仍基于旧理解推进，将导致“目标错位却用力推进”，这是长期主动最危险的失败模式。
03
既然主动性源于「差距 → 问题」，分层标准自然取决于“谁定义了问题”。可从两根轴进行解析。
3.1 横轴：谁定义问题
图 4 · 横轴：谁定义问题（L1–L5）
L3 到 L4 是质变节点。
L1 至 L3 阶段，无论表现多么智能，问题均由用户定义：L2 的时间规则、L3 的触发条件皆由用户设定，Agent 仅在合适时机执行。
进入 L4 阶段，用户仅提供目标，“缺什么、补什么”由 Agent 自行计算。L4 的前提是差距可计算，即目标清晰、可量化或具备可检查的状态。
L5 则是 Agent 自行推断目标；若 L4 的目标表述不清，实际上会退化为 L5。
3.2 纵轴：做到哪一步
横轴解决“问题来源”，纵轴则解决“执行深度”。同为 L4，“提醒依赖未认领”与“直接在群里认领”性质截然不同。
因此引入第二根轴：
图 5 · 纵轴：做到哪一步
两根轴相互独立。L5 级别的 Agent 可仅停留在“告知”，而 L3 级别的 Agent 也可直接对外执行。评估 PA 能力时，必须明确其在双轴上的坐标。
04
笔者构建了一个名为 Daisy 的 PA，包含以下常驻 Loop：
- 每日收敛 Loop：每晚 20:00 扫描当日会话、钉钉群、关键私聊及文档，产出待办事项（Todo）和潜在价值话题（Discover）。
- 自动回复 Loop：在白名单群组中被 @ 时，按规则代为回复。
将其映射至双轴模型：
横向来看，已达到 L4/L5 水平：Todo 基于工作目标差距计算，Discover 基于兴趣推断。
纵向来看，两者均停留在较低的执行层级。
4.1 数据很诚实
自 7月1日 起，每日 Loop 共产出 276 条 Todo，其中 138 条标记为完成。这 138 条中有 126 条是在 8月13日 的一次会话中集中手动核销的。由 Loop 自动执行并关闭的数量为：0。
Daisy 每天都在「发现问题」，但从未「解决问题」。所有执行与收尾工作最终仍由人工完成。
4.2 是太谨慎了吗？
并非如此。观察同一 PA 中的自动回复 Loop：
它可直接在钉钉群中代为回复同事。这是一个对外、不可逆的高风险动作。但我放心交予它，因为规则完全由我制定：
问题由我定义，边界由我划定，责任由我承担。因此敢于放权。
相比之下，Todo 是 Agent 自行计算的问题。若其判断失误并擅自执行，后果无人承担。在此责任归属问题解决前，只能让其停留在“建议”阶段。
4.4 升仓：同一件事，可以从 L5 走到 L4
Discover 是另一个典型案例。虽然扫出了80多个话题，但我并未直接将其沉淀入库。
未直接入库的原因有二：一是时间精力有限；二是担心自动生成内容质量不足。
但若调整设定，情况则不同。若在 PA 场景中明确设定“成为某领域专家”的目标，并给出清晰的入库规则：
- 知识架构清晰，能挂载至现有概念体系；
- 来源扎实，优先官方文档和一手资料；
- 与库内既有结论不冲突，若有冲突则标出。
在风险可控前提下，部分入库工作可由 Agent 自主完成。
图 6 · 同一件事从 L5 走到 L4
这一变化的核心不在于 Agent 能力的提升，而在于用户交付内容的改变：提供了可计算的目标和可检查的验收规则。
05
决定是否交由 Agent 执行，关键不在于层级高低或个人谨慎程度，而取决于两个核心问题：
1. 问题是谁定义的？这决定了出错时的责任归属。
2. 失败代价有多大？具体考量三点：是否可撤回、影响范围、结果是否可验证。
据此可将待办分为五档，每档对应真实案例：
可视化图表如下：
图 7 · 能不能交给 Agent 执行
左下角区域最适合直接执行：问题由用户定义，且试错成本低。越往右上移动，越需要人工在关键节点把关。
06
L1 至 L3 的执行已相对成熟：问题与边界由用户界定，Agent 按规则执行。真正的瓶颈在于 L4 的执行与 L5 的全流程。
6.1 L4：Agent 定义了问题，责任却还在人身上
L4 的问题由 Agent 计算得出。算对则省力，算错则用户担责。这种权责不对称导致用户倾向于将 L4 限制在“建议”层面。
长周期加剧了这一困境。目标随时间漂移，若 Agent 基于旧目标推进，差距计算越精准，偏离越远。因此，L4 向上突破需建立持续对齐机制，在关键节点重新确认目标有效性。
6.2 L5：在 L4 的风险上，再叠一层"目标猜错"
L5 连目标均由 Agent 推断，引入了双重误差风险：
- L4 风险：目标正确，但差距计算错误。
- L5 风险：目标本身推断错误，导致后续差距、问题、任务全线偏差。
现实中，如 Meta Muse 等系统试图推断用户“未言明”的目标，需读取大量隐私数据，引发争议。推断能力虽存，但用户接受度有限。因此，当前 L5 更适合停留在“告知”阶段：由 Agent 提供观察结果，由用户判定是否为其目标。
6.3 杠杆：把目标和验收规则说清楚
推动层级跃升的关键杠杆在于：
图 8 · 杠杆：把目标和验收规则说清楚
- 明确目标：Agent 无需猜测，L5 转化为 L4。
- 明确验收规则：“对错”可被检查，L4 部分转化为“按规则执行”，问题定义权与责任回归用户。
层级跃升路径为：从“猜测关注点”到“对照专家目标算差距”，再到“符合规则直接入库”。
PA 主动性的放大程度，不仅取决于 Agent 的智能水平，更取决于用户阐明目标与规则的清晰度。Agent 负责精准计算差距与推进事务；用户负责明确方向底线并及时校准漂移目标。
主动性的上限，即是人与 Agent 之间能够显式对齐的那部分目标。部分目标。
这套分层理论不仅探讨 Agent 的智能程度，也反向定义了 PA 产品所需的基础设施：稳定的身份与记忆以维持跨会话目标，Channel 与 Schedule 提供事件与时机，云端执行环境保障离线持续行动；而权限、确认机制与运行记录，则用于承接不同执行层级的风险。
若您希望将长期目标、个人上下文与持续执行转化为真正可用的 Personal Agent，可参考以下方案：https://qoder.com/zh/cloud-agents
