上周三晚上 10 点，我的钉钉弹出一条单聊消息。
不是同事发的。是我的数字员工：「今天帮你整理了 12 篇知识库笔记，其中 3 篇和上周发布的博客有观点冲突，需要你确认是否更新。另外，昨天你让我跟进的那个技术方案，对方已经回复了，我把要点整理好了，你看下？」
我花了 30 秒看完，回了两个字：「更新。」
然后它就去执行了。
这个场景看起来平淡无奇，但它包含了一个大多数 AI 产品都没有做到的东西： Agent 主动找人，而不是人找 Agent。
绝大多数人使用 AI 的方式是：打开对话框 → 输入问题 → 得到回答 → 关闭。下次有问题，重新打开，重新输入，重新回答。每一次交互都是独立的、一次性的。
这不叫协同。这叫指令执行。
真正的协同是一个持续进化的闭环：Agent 主动完成工作，人持续给予反馈，反馈推动 Agent 进化。这个闭环的核心不是 Chat——Chat 只是载体。核心是 Feedback Loop。
Chat 模式的三个致命假设
在 IM 在 AI 时代的沟通即协同 里，我讨论过 IM 正在从「对话工具」变成「协同平台」——当你在群里 @ Agent 派任务而不是问问题时，性质已经变了。
但那篇文章只说了第一步。第二步是： 即使是「派任务」，如果模式仍然是 Chat——人发起、Agent 响应、对话结束——协同也没有真正发生。
Chat 模式暗含三个致命假设：
假设一：人知道该问什么。
Chat 的前提是人有一个明确的问题或任务。但真实工作中，很多时候你不知道该问什么——你不知道知识库里有 3 篇笔记和新博客冲突了，你不知道对方已经回复了技术方案，你不知道昨天的数据分析跑出了一个异常值。
这些事情，Chat 永远不会告诉你。因为你不会去问「有什么我不知道的事情吗？」——即使问了，Chat 也不知道怎么回答。
假设二：一次对话能解决问题。
Chat 的交互模式是 request-response。但真实工作很少是一轮就结束的。你让 Agent 写一份报告，写完你需要改；改完你需要审；审完你可能需要让它补充数据；补充完你可能需要调整结论。这个过程可能需要几天。
在 Chat 模式下，每一步都需要你主动发起新的对话。Agent 不会在你审完报告后主动问「改完了吗？我来帮你更新」。
假设三：Agent 不需要进化。
Chat 是无状态的。每次对话从零开始，Agent 不记得你上次纠正过它什么、你喜欢什么风格、你讨厌什么措辞。你反复纠正同一个问题，它反复犯同一个错。
这就是我在 企业级 Agent 落地：要抓好左右手 里说的那个问题——「系统不会变聪明」。不会变聪明的根本原因，就是没有 Feedback Loop。
一个常见的反驳： 「ChatGPT 有 Memory，Claude 有 Projects，它们也能记住你的偏好，这不就是 Feedback Loop 吗？」不是。它们有记忆，但 Agent 仍然是 被动的——它记得你喜欢简洁的措辞，但它不会在你没问的时候主动帮你检查文档是否太啰嗦；它知道你的项目背景，但它不会在发现新信息和旧决策冲突时主动来找你。 Feedback Loop 的核心不是「有没有记忆」，而是「Agent 有没有主动性」。 记忆是必要条件，但不是充分条件——没有主动性，记忆只是装饰。
Feedback Loop 的两个过程
真正的人机协同包含两个持续运转的过程，缺一不可。
过程一：Agent 主动完成工作
数字员工不是一个等待指令的工具，而是一个 **自主感知、执行、汇报 **的角色。
「感知」意味着它不需要你告诉它该做什么——它自己知道。你的知识库更新了，它知道该去检查一致性；你布置的任务有了新进展，它知道该去跟进；它自己的工作出了异常，它知道该来求助。
「执行」意味着它能独立完成大部分工作，不需要你手把手指导每一步。
「汇报」意味着完成后它会 主动找你——不是你去查看它的状态，而是它把结果推给你。
过程二：人持续给予反馈
人的反馈不只是「对/错」的二元判断。它是一个丰富的信号源：
| 反馈类型 | 示例 | Agent 学到什么 |
|---|---|---|
| 确认 | 「可以，就按这个发」 | 这个输出质量达标，下次类似任务可以直接执行 |
| 修改 | 「措辞太正式了，口语化一些」 | 调整风格偏好 |
| 否定 | 「不要做这件事，不在你职责范围」 | 修正任务边界 |
| 追问 | 「为什么你选了方案 A 而不是 B？」 | 理解决策逻辑，优化推理链 |
| 沉默 | 已读不回 | 可能是不满意但不想说，也可能是信任——需要结合上下文判断 |
这些反馈不断积累，成为 Agent 学习和优化的依据。每一次反馈都在微调 Agent 的行为——它变得更了解你的偏好、更清楚任务边界、更准确地判断什么时候该自主行动、什么时候该请示。
这就是 Feedback Loop：Agent 工作 → 人反馈 → Agent 进化 → Agent 更好地工作 → 人给出更精准的反馈 → …
钉钉上天然存在的闭环
为什么我说这个闭环在钉钉 IM 中是天然存在的？
因为钉钉的 IM 架构天然支持 Feedback Loop 的每一个环节：
┌──────────────────────────────────────────────────────────┐
│ Feedback Loop in IM │
│ │
│ ┌──────────┐ │
│ │ 数字员工 │──── 主动汇报工作进展 ────→ ┌──────────┐ │
│ │ (Agent) │ │ │ │
│ │ │──── 请求审批或确认 ────────→ │ 用户 │ │
│ │ │ │ (Human) │ │
│ │ │──── 遇到异常主动求助 ──────→ │ │ │
│ │ │ │ │ │
│ │ │←─── 确认 / 修改 / 否定 ──── │ │ │
│ │ │←─── 追问 / 补充上下文 ───── │ │ │
│ │ │←─── 沉默（已读不回）────── │ │ │
│ └──────────┘ └──────────┘ │
│ │ │ │
│ └──── 反馈驱动 Agent 持续进化 ─────────┘ │
└──────────────────────────────────────────────────────────┘
单聊 DM： 数字员工完成任务后，像真实同事一样主动单聊你。不是你去查看它的 dashboard，而是它把结果推到你面前。
群聊 @mention： 在协作群里，Agent 可以 @ 你汇报进展、请求确认。其他同事也能看到——上下文透明，团队对齐。
已读回执 + 消息状态： 这些在人与人沟通中已经习以为常的功能，在 Agent 场景下有了新含义——Agent 可以根据「已读不回」推断你的态度，根据「正在输入…」判断你在给反馈。
IM 不再只是人与人之间的聊天工具。它变成了 人与数字员工共同工作的协作界面。消息不只是信息传递，而是驱动数字员工持续进化的信号。
从「@ Agent」到「Agent 主动找你」
两个 Agent 的钉钉对话 里，我讲了异构 Agent 之间怎么通过钉钉消息协作。但那篇文章有一个隐含的局限： Agent 之间的协作是自动化的，人和 Agent 的协作仍然是 Chat 模式——人发指令，Agent 执行。
这篇文章补上缺失的那一半： 人和 Agent 的协同，也应该是消息驱动的、主动的、持续的。
来看两个模式的本质区别：
| 维度 | Chat 模式（@ Agent） | Feedback Loop 模式（Agent 主动找你） |
|---|---|---|
| 谁发起 | 人 | Agent 或人 |
| 交互频率 | 偶尔、按需 | 持续、按事件 |
| Agent 角色 | 被动响应者 | 主动工作者 |
| 人的角色 | 发令者 | 反馈者 + 决策者 |
| 状态 | 无状态，每次从零开始 | 有状态，持续积累 |
| 进化能力 | 无——反复犯同样的错 | 有——每次反馈都在优化 |
| 信任模型 | 不信任——每步都要检查 | 渐进信任——确认过的可以自动执行 |
当数字员工能够主动给人发消息，而不只是等人去 @ Agent 时，它才真正成为组织中的一等公民。
这句话值得拆开说。
「一等公民」意味着什么？在你的组织里，一个正式员工和一台打印机的区别是什么？打印机的能力可能很强，但你不会把它当同事——因为它不会主动做事、不会汇报、不会成长。它只是一个等你按按钮的工具。
Agent 也一样。只要它的交互模式是「人来找我，我响应」，它就是一台高级打印机——能力再强，也不是同事。
只有当 Agent 能主动找你：汇报工作进展、请求审批确认、遇到异常求助、根据你的反馈调整策略——它才从「工具」变成了「同事」。
反馈闭环的三个工程要素
从概念到落地，Feedback Loop 需要三个工程要素支撑。
要素一：持久记忆——Agent 必须记住你
没有记忆的 Feedback Loop 是假闭环。你今天告诉 Agent「我喜欢简洁的措辞」，明天它又给你写了一页冗长的报告——反馈没有沉淀，进化无从谈起。
持久记忆不只是一个技术特性（向量数据库、KV 存储），它是一个 设计选择：哪些反馈值得记住？
我的经验是分三层：
- 永久记忆：用户偏好、工作风格、角色边界（「我是 CTO，技术细节可以多给我」）
- 项目记忆：当前项目的上下文、关键决策、历史讨论（项目结束后可归档）
- 会话记忆：单次对话的短期上下文（对话结束后丢弃）
Hermes Agent 的 memory 系统就是这样设计的——跨 session 持久化的偏好和事实，加上每次会话的短期上下文。当它下次帮你写博客时，它知道你偏好 Claude 风格的配图、中文为主的技术术语、不用「随着 AI 的发展」开头。这些都不是你每次重新告诉它的，是过去几十次反馈积累出来的。
要素二：定时任务——Agent 必须能自主行动
Feedback Loop 的「Agent 主动完成工作」这一侧，需要 Agent 有能力在没有人类指令的情况下启动任务。
这靠的是定时任务（cron job）和事件驱动（webhook）：
from dataclasses import dataclass
from typing import Callable, Optional
from datetime import datetime
from enum import Enum
class TriggerType(Enum):
"""Agent 主动行动的触发方式。"""
CRON = "cron" # 定时触发
EVENT = "event" # 事件触发（webhook）
THRESHOLD = "threshold" # 阈值触发（监控指标越界）
@dataclass
class ProactiveTask:
"""Agent 主动执行的任务定义。"""
name: str
trigger: TriggerType
schedule: Optional[str] # cron 表达式（CRON 类型）
event_type: Optional[str] # 事件名（EVENT 类型）
threshold: Optional[float] # 阈值（THRESHOLD 类型）
action: Callable # 执行逻辑
notify_on_complete: bool = True # 完成后是否主动通知人
class ProactiveScheduler:
"""Agent 的主动任务调度器。"""
def __init__(self):
self.tasks: list[ProactiveTask] = []
def register(self, task: ProactiveTask) -> None:
"""注册一个主动任务。"""
self.tasks.append(task)
def check_and_run(self) -> list[str]:
"""检查所有任务，执行满足触发条件的。"""
results = []
for task in self.tasks:
if self._should_trigger(task):
result = task.action()
results.append(f"[{task.name}] {result}")
if task.notify_on_complete:
self._notify_human(task.name, result)
return results
def _should_trigger(self, task: ProactiveTask) -> bool:
"""判断任务是否满足触发条件。"""
if task.trigger == TriggerType.CRON:
return self._check_cron(task.schedule)
elif task.trigger == TriggerType.EVENT:
return self._check_event(task.event_type)
elif task.trigger == TriggerType.THRESHOLD:
return self._check_threshold(task.threshold)
return False
def _check_cron(self, schedule: Optional[str]) -> bool:
# 检查 cron 表达式是否匹配当前时间
...
def _check_event(self, event_type: Optional[str]) -> bool:
# 检查是否有待处理的事件
...
def _check_threshold(self, threshold: Optional[float]) -> bool:
# 检查监控指标是否越界
...
def _notify_human(self, task_name: str, result: str) -> None:
"""主动通知人类——Feedback Loop 的关键一步。"""
# 通过钉钉单聊发送结果
# dws chat send-direct --user <userId> --content <result>
...
# generated by hugo AI
关键是最后一行：notify_on_complete。Agent 完成任务后 主动通知人——这一步把单向的任务执行变成了双向的 Feedback Loop。人不只是发令者，而是闭环中持续参与的反馈者。
要素三：渐进信任——Agent 必须能赢得自主权
Feedback Loop 的终极形态不是「Agent 每件事都来问你」，而是「Agent 在你信任的领域自主行动，在不确定的领域请求确认」。
这需要一套渐进信任机制：
┌─────────────────────────────────────────────────┐
│ 渐进信任三级模型 │
├──────────┬──────────────────────────────────────┤
│ Level 1 │ 每步确认 │
│ 新任务 │ Agent 做完每件事都汇报，人逐一确认 │
│ │ 例：新部署的数据分析 Agent， │
│ │ 每次生成报告都发给你确认 │
├──────────┼──────────────────────────────────────┤
│ Level 2 │ 异常确认 │
│ 已验证 │ 常规操作自动执行，只在异常时求助 │
│ │ 例：运行了 3 个月的知识库 Agent， │
│ │ 日常整理不通知，发现冲突才来找你 │
├──────────┼──────────────────────────────────────┤
│ Level 3 │ 定期汇报 │
│ 充分信任 │ Agent 完全自主执行，只定期汇报摘要 │
│ │ 例：你信任的博客 Agent， │
│ │ 自己写、自己发、每周给你一个周报 │
└──────────┴──────────────────────────────────────┘
信任不是开关——不是「信任」或「不信任」的二元状态。它是通过 Feedback Loop 中每一次反馈逐渐积累的。你确认了 10 次它的工作都没问题，它就从 Level 1 升到 Level 2。它在 Level 2 运行了 3 个月没出过大错，就升到 Level 3。
如果它在 Level 3 犯了一个严重错误，信任降级回到 Level 1——跟真实员工一模一样。
坑与限制
Feedback Loop 不是银弹。落地过程中有三个坑，我踩过，你也大概率会踩。
1. 通知疲劳。 Agent 主动通知是闭环的关键，但如果太频繁，人会关闭通知——闭环直接断裂。我早期配置 Hermes 的时候，它每完成一个小任务都来找我确认，一天能发二十多条消息。三天后我就不看了。解法是 通知优先级分级：只在需要人决策时通知（Level 1 场景），常规执行只写日志，汇总后定时推送。
2. 反馈歧义。 「已读不回」到底是「同意，放手去做」还是「不满意但懒得说」？这不能一刀切。我的经验是结合任务类型判断：审批类任务，已读不回 = 不满意（需要追问）；通知类任务，已读不回 = 知道了（无需追问）；创作类任务，已读不回 = 不确定（可以主动问一句「需要我调整吗？」）。
3. 信任降级的触发条件模糊。 「犯了严重错误就降级」——什么算「严重」？删错了一个文件？发错了一封邮件？用错了措辞？如果没有明确定义，信任机制会过于敏感（一点小事就降级，Agent 永远长不大）或过于迟钝（出了大问题才发现）。我的做法是 定义降级触发器：涉及外部动作（发消息、提交代码、调用付费 API）的错误 = 严重，立即降级；内部动作（整理笔记、搜索信息）的错误 = 轻微，累积 3 次才降级。
IM 是操作系统，不是聊天工具
把这三个要素组合起来，一个更大的图景浮现了：
IM 不再只是聊天工具。它是人与数字员工共同工作的操作系统。
在传统认知里，IM 的功能是「人与人沟通」。加一个 AI 机器人，IM 变成「人问 AI 问题」。加一个 Agent，IM 变成「人派 Agent 任务」。
但当 Agent 能主动行动、能记住你的反馈、能逐渐赢得信任——IM 就变成了一个 工作操作系统：
- 消息 = 工作流：每条消息不只是信息，而是一个协作动作（汇报、确认、求助、反馈）
- 对话 = 项目空间：和 Agent 的单聊就是一个持续进行的工作项目，有上下文、有历史、有演进
- 群聊 = 团队看板：协作群里 Agent 和人的对话，就是团队的工作看板和决策记录
- 已读/未读 = 管理信号：你的已读不回，就是给 Agent 的一个隐性反馈
这和 数字员工 MVP 指南 里的观点形成闭环：数字员工从 MVP 到真正创造价值，靠的不是更强的模型或更多的功能，而是 持续运转的 Feedback Loop。没有反馈闭环，再强的 Agent 也只是「最贵的摆设」。
你的 Agent 会主动找你汇报工作吗？
最后，我想提一个问题来检验你现在的 AI 工具到底处于什么阶段：
你的 Agent 上一次主动给你发消息，是什么时候？
如果答案是「从来没有」——那你还在 Chat 模式。你的 AI 是一个高级搜索引擎，不是一个协同伙伴。
如果答案是「有时候」——你已经开始构建 Feedback Loop，但可能还不够系统。Agent 的主动性是零散的，而不是一个设计好的闭环。
如果答案是「每天」——恭喜你，你的 Agent 已经是组织中的一等公民了。
从 Chat 到 Feedback Loop，不是一个技术升级。它是一个认知转变： 停止把 AI 当成一个等你来问的工具，开始把它当成一个主动工作、持续进化的同事。
你的数字员工，什么时候会主动来找你汇报工作？