我是安徽最忧郁程序员无隅

前言

Agent 每天整理消息、生成待办，还会主动提醒我们处理问题。但待办列表持续增长，实际工作可能仍然需要人来完成。怎样让它知道哪些事情值得处理，又怎样决定它可以自行执行到哪一步？本文从信息来源、目标差距和执行范围三个方面解释这些问题，并用项目里程碑与知识库整理案例说明具体判断过程。

一、Agent 怎样持续接触用户的工作环境？

让 Agent 参与日常工作，首先需要让它接触任务描述之外的信息。项目状态可能记录在工作项里，需求变化发生在群聊中，某项决定的原因又藏在上周的讨论里。这些信息会持续变化，用户在对话开始时整理的一份背景，无法一直反映最新情况。

一个持续工作的 Personal Agent，需要解决三个相互关联的问题：它以什么身份访问系统，能够读到哪些变化，以及这些变化为什么与当前用户有关。

身份与权限决定它能够访问什么。 例如，Agent 使用已经授权的身份读取一个项目的工作项、接收某个群聊的消息，并通过指定渠道反馈结果。用户离开聊天窗口以后，这些访问和反馈仍然需要明确的身份及权限依据。

外部数据提供当前发生的事情。 工作项新增、代码评审通过、会议时间改变，都会带来新的状态。系统可以定时读取，也可以订阅事件，在变化发生后启动处理。

长期记忆保留理解这些变化所需的个人背景。 同样一条“接口评审推迟”的消息，对不同用户的意义不同。参与该项目的人可能需要调整安排，旁观者可能只需要知道结果。之前确认的目标、职责、偏好和决定，有助于 Agent 判断消息的相关性。

这三部分各自承担具体职责。独立身份让访问和反馈具有连续性；数据来源让系统接触现实变化；保留的背景让这些变化能够与用户正在进行的事情建立联系。系统还需要运行环境和触发机制，才能在用户没有打开对话窗口时继续处理工作。

触发方式	系统怎样得到处理时机	工作示例
定时检查	在约定时间读取当前状态	每天检查项目里程碑的进展
事件订阅	外部系统出现相关变化后通知 Agent	代码评审出现新意见后继续处理

例如，Qoder Cloud Agents 的官方文档分别定义了 Agent 配置、运行环境、执行会话和事件流，并说明可以结合调度器运行周期性检查。这些能力提供执行条件，具体业务仍然需要定义检查对象、目标和处理规则。Qoder Cloud Agents 官方概览

接入信息之后，还要回答一个更具体的问题：这条变化是否意味着用户需要处理某件事情？

二、知道发生了什么以后，怎样发现值得处理的事情？

假设一个项目要求在月底交付三个功能，每个功能都需要通过代码评审和业务验收。

Agent 检查工作项时发现，第三个功能还没有通过验收。这个发现是否需要产生待办，要结合期限和当前进度判断：如果验收安排在明天，已有负责人正在处理，当前状态可能符合计划；如果今天就是截止日期，验收仍然没有负责人，就存在需要处理的条件。

明确目标和当前状态，才能说明具体缺少什么。 在这个例子中，目标包含截止时间、功能范围和完成条件；现状包含已经完成的工作、仍待处理的事项和责任人。将它们联系起来，Agent 才能够提出“第三个功能缺少验收负责人”这样的具体问题。

下图中的三类输入共同参与判断。个人背景帮助理解约定，目标说明完成条件，现状提供可核查的进展。

把“目标差距”解释成可以检查的条件

原文使用“目标与现状之间的差距”解释主动性。放到实际系统中，可以把它理解为：检查目标要求的条件，还有哪些没有满足，并说明判断依据。

差距可以表现为数量，也可以表现为状态。例如，三个功能已经验收两个，可以指出剩余数量；某个功能没有负责人，则需要读取责任分配记录。对于“业务已经验收”这样的条件，还需要找到对应的验收结论，单靠代码已经提交无法完成判断。

因此，Agent 提出的事项需要包含具体依据。以项目验收为例，它应当说明涉及哪个功能、依据哪条完成条件、当前缺少什么，以及建议谁来确认。人看到这些信息以后，才能判断它是否发现了真实问题。

如果系统读取不到验收记录，它可以报告“缺少可核实的验收结果”。缺少记录与业务尚未验收属于两种状态，后续动作也不同：前者需要补充证据，后者才可能需要安排验收。

长期目标需要持续检查其有效性

一次短任务的完成条件通常相对稳定。持续几周的目标可能发生变化：某个功能延期，项目优先级调整，或者原本需要交付的内容被取消。

Agent 如果继续按照旧目标检查差距，就可能产生已经失效的待办。因此，长期任务需要保留当前采用的目标和规则，并在关键变化发生时重新确认。比如，项目范围调整后，后续检查应当使用新范围；对于含糊的变化，则先提出待确认的问题。

目标还需要与具体动作分别记录。用户要求“推动这个里程碑完成”，提供了工作的方向；发送跨团队消息、修改配置或代替用户作出承诺，还需要各自适用的授权条件。

三、主动发现问题与主动执行，需要分别衡量

本文采用来源文章提出的 L1–L5 分析框架，讨论不同工作的问题从哪里产生。它适合帮助我们描述具体行为，使用时需要结合任务内容和执行条件。来源文章

分类	问题怎样产生	示例
L1 指令	用户直接提出任务	整理指定文档中的关键结论
L2 时间	用户预先规定周期性工作	每天早上汇总前一天的消息
L3 外部事件	用户预先规定触发条件	评审出现新意见后启动处理
L4 持续目标	用户明确目标，Agent 检查未满足的条件	发现月底交付的功能仍缺少验收负责人
L5 推断目标	Agent 根据表达或行为推断用户意图，再提出事项	根据近期讨论推测用户可能关注某个研究方向

从 L3 到 L4，需要增加一项判断：除了识别事件，还要依据目标发现应该处理的问题。L5 又增加了目标推断，系统需要猜测用户真正想达成什么。目标推断是否正确，也需要得到验证。

这里还要区分启动时机与任务内容。一个检查每天定时运行，说明它有固定触发时间；如果检查内容是依据项目目标发现新的遗漏，那么它同时包含持续目标的判断。分析具体行为时，需要观察系统依据什么提出工作。

发现问题以后，执行范围仍然需要明确

发现“这个功能缺少验收负责人”以后，Agent 可以有不同的动作：告知用户当前状态，建议联系相关人员，起草一条沟通消息，或者在授权范围内直接发送。

这些动作面对同一个问题，却具有不同的影响。提醒用户需要安排验收，与代表用户承诺某个时间完成验收，需要的条件不同。

下图分别列出问题来源与执行范围。上下两组各自独立，同一列中的标签没有一一对应关系。

能够发现更复杂的问题，仍然需要单独确定可以采取哪些动作。 例如，系统依据预设规则，在指定群聊中回复一条已经确认的公告，可以属于事件触发下的对外执行；系统推测用户可能对某个方向感兴趣，也可以只提供一个观察结果，等待用户确认。

因此，描述一个 Personal Agent 时，可以把具体行为说完整：“它根据长期项目目标发现遗漏，起草处理建议，由用户确认后发送。”这句话同时交代了问题来源和执行范围，便于讨论系统究竟承担了哪部分工作。

四、为什么能够发现待办，却迟迟无法完成工作？

来源文章中，作者介绍了自己搭建的个人 Agent——Daisy。它会定时阅读当天的信息，整理待办和可能值得进一步研究的话题；另外，它也会在预先规定的群聊与规则范围内进行自动回复。

作者给出的待办记录中，共产生 276 条待办，其中 138 条标记为完成。文章进一步说明，有 126 条是在一次会话中由作者集中手动关闭的，Agent 自行执行并关闭的待办数量为 0。

这些数字来自原作者的个人使用记录，材料中没有附上底层运行日志。它们呈现了该案例中建议与执行的分布：待办能够被发现，实际交付仍然主要依赖人工处理。不能将“标记完成”的数量直接当成 Agent 自行完成工作的数量。

自动回复与自动处理待办，为什么有不同条件？

同一个系统能够在群聊中自动回复，却无法自行处理所有待办，原因需要从具体规则中寻找。

原作者为自动回复限定了接收范围、话题和时效，也约定了已经有人处理时怎样避免重复回应。系统得到的是一项具有明确条件的工作：什么情况下回复，能够说什么，遇到哪些情况需要停止回应。

从持续目标推导出的待办，则可能只说“这个依赖需要有人处理”。要完成它，还需要确定谁负责、怎样沟通、是否改变已有安排，以及完成以后怎样检查。发现问题时使用的依据，尚未覆盖执行阶段的全部条件。

从建议走向交付，需要把具体动作、完成条件和授权范围补充清楚。 模型能够提出合理建议，并不能直接证明它已经具备执行该建议所需的业务信息与权限。

判断执行范围时，检查三个具体问题

原文用失败代价解释不同工作的处理方式。实际分析时，可以分别检查以下三个问题：

• 动作能否撤销？ 整理一份可修改的草稿，与发出一条已经被对方看到的承诺，撤销条件不同。
• 会影响哪些人或系统？ 整理个人笔记、通知协作者和改变公开业务行为，影响范围逐步扩大。
• 结果能够怎样验证？ 检查工作项是否进入指定迭代，可以读取明确状态；判断某项承诺是否符合团队安排，则还需要相关人员确认。

这些问题需要一起考虑。一个动作即使能够撤销，也可能已经影响到其他人的判断；一个结果即使可以检查，也仍然需要相应的执行授权。

例如，Agent 可以在获准访问的范围内核对工作项，报告遗漏并保留检查依据。对于“明天上午将修改后的演示文稿发给客户”这样的事项，可以先完成材料草稿，交由用户确认内容和发送安排。处理方式取决于该项工作的具体条件。

对外沟通也可以通过预先确认的规则获得授权，但规则需要覆盖接收对象、内容范围和例外情况。执行过程中遇到新的承诺或规则没有覆盖的问题，应当将相关信息交回具有决定权限的人处理。

五、用知识库整理案例，讲清目标与验收规则的作用

假设我们希望 Agent 帮助维护一份 Agent 系统学习知识库。它可以阅读已经接入的学习记录和资料，发现值得整理的话题。以下过程用于说明设计方法，尚未在本文中部署运行。

如果目标只有“帮助我学得更好”，系统还需要猜测学习方向、内容深度和资料质量。它发现一个有趣话题以后，也很难判断这个话题应该进入知识库的哪个位置。

我们可以把目标写成更容易检查的要求：在本月结束前，补齐执行循环、工具调用、上下文管理、会话恢复、授权控制、长期记忆、事件触发和评测这八个核心概念。每个概念都需要说明解决的问题、关键机制，并附上能够支持结论的一手来源。

这个设定给出了范围与完成条件。Agent 读取知识库后，就可以检查哪些概念已经覆盖，哪些还缺少机制解释或可靠来源，再提出有依据的整理任务。

验收规则决定什么内容可以进入知识库

明确知识范围以后，还需要说明怎样判断候选内容的质量。可以采用以下规则：

• 内容能够归入约定的核心概念，并说明与已有条目的关系。
• 关键事实具有可定位的来源，优先使用官方文档、原始论文和项目源码。
• 引用来源直接支持相应结论，并保留适用条件和版本信息。
• 与已有内容重复时，补充缺少的解释或证据；结论冲突时，列出依据并请求确认。
• 已验证的事实、作者观点和教学示例分别说明归属。

例如，Agent 读到一篇介绍事件触发的资料，发现知识库已经解释了定时轮询，却缺少订阅外部事件的处理过程。它可以定位这项缺失，检查来源，再起草补充内容。

如果资料仅仅宣称“这种方案更可靠”，却没有说明适用场景或提供证据，候选内容还无法满足验收要求。Agent 应当指出缺少什么，继续查找来源，或者提交待确认的草稿。

写入授权决定符合规则后能够采取什么动作

质量验收通过以后，还需要确认是否允许修改知识库。假设用户已经允许 Agent 在指定目录新增满足规则的学习条目，并保留来源和变更记录；删除既有结论、修改知识分类和覆盖冲突内容，则需要人工确认。

在这个范围内，Agent 可以为已有概念新增经过检查的解释，写入以后再读取结果，确认内容、引用和保存位置符合要求。遇到目标范围不清、证据冲突或授权尚未覆盖的情况，则准备草稿与依据，交由用户决定。

下图中，上半部分先检查目标、内容与授权。条件分支分别展示可以写入的情况，以及需要人工确认的情况。

这里的三个条件各有作用：目标帮助系统判断哪些知识值得补齐，验收规则帮助检查内容质量，授权说明允许修改哪些资源以及需要在哪些节点确认。

来源文章中的知识整理案例，也表达了类似的变化：用户说明学习目标和内容验收条件以后，系统能够依据更明确的要求整理材料。对于“成为某领域专家”这样的长期愿望，仍然需要落实为可检查的阶段目标；八个概念的覆盖情况只检验这项整理任务的完成程度。

持续整理还需要处理目标变化和判断不确定性

假设学习重点从事件驱动改成评测，继续大量收集事件机制的资料，就可能偏离当前需要。Agent 应当保留当前采用的目标与验收要求；收到新的明确决定后，后续检查使用更新后的要求。无法判断影响范围时，提出具体问题等待确认。

如果来源暂时无法访问，也不能把“当前没有查到依据”写成“这个结论错误”。系统可以保留待核实状态，说明缺少的材料，并在获得证据以后继续处理。

交付结果可以采用可核查的记录：本次补充了哪个概念、参考了哪些来源、修改了什么内容，以及哪些问题仍然等待确认。用户据此能够检查执行质量，也能够决定是否调整下一次工作的目标或规则。

参考资料

本文基于阿里技术发布的 Personal Agent 主动性讨论重新组织讲解。L1–L5 分类与 Daisy 的个人使用记录来自原文，项目里程碑和八个核心概念的知识库整理过程为本文的教学示例。

• 来源文章：Personal Agent 主动性实践思考
• Qoder Cloud Agents 官方概览：配置、运行环境、会话与事件

资料核实日期：2026 年 11 月 2 日。