一个人类员工一天审批 20 单、发 50 封邮件、访问 10 个系统。如果权限有漏洞，损害上限是 20 单。
一个 Agent 一秒调 100 次 API。一分钟 6000 次，十分钟 60000 次。如果权限有漏洞，你甚至来不及发现，损害就已经是 指数级 的。
这不是量变，是质变。传统权限模型（RBAC / ABAC）有一个隐含假设： 操作者是人，操作速度是人的速度。 这个假设在 Agent 时代彻底失效了。
再加上三个新问题：委托链（人委托 Agent A，A 调用 Agent B，B 访问系统 C）、上下文依赖（同一个 Agent 在不同群里有不同权限）、可被操纵（Agent 可能被 prompt injection 劫持）——传统权限模型不是「需要升级」，而是 需要重新设计。
[Read More]晚上 10 点，纽约的产品经理在 Linear 上建了一个竞品分析的 ticket，在群里 @ 了东京的工程师，又发了一封邮件给伦敦的设计师。三个渠道，三种状态，没有一个地方能看到全貌。
第二天早上，产品经理问：「进度怎么样了？」东京说：「刚看到群消息，还没开始。」伦敦说：「邮件？我昨天没在线。」Linear 上的 ticket 状态还是 To Do——因为没人记得去更新它。
这个场景每天都在全球化团队里上演。我们用了二十年时间解决「人怎么跨时区协作」——异步文档、录屏、standup 录音、follow-the-sun 排班。但本质上，所有方案都在做同一件事： 让不在场的人也能跟上进度。
如果有一种同事，它没有时区、不需要睡觉、7×24 在线、能在你下班后继续推进工作呢？
这种同事已经存在了。它叫 Agent。但我们的协同办公产品——通讯录、IM、邮件——还没有为它做好准备。
[Read More]昨晚十一点半，我盯着自己那个钉钉数字员工项目里的一段代码发呆。
那是 core 模块里的轮询逻辑——每隔 3 秒去 serve 端拉一次会话状态，判断任务是否完成、是否超时、是否需要 abort。旁边是 session 管理：维护一个内存里的 Map，记录每个会话的生命周期、重试计数、上下文快照。再往下是 abort 清理：当用户取消任务时，要优雅地终止正在执行的工具调用、回收资源、把中间状态写回。
加起来大概 200 行。写得挺漂亮，有状态机、有超时退避、有异常兜底。我三个月前写它的时候，serve 端还没有原生的会话生命周期管理，没有 SSE 事件流推送，没有内置的 abort 语义。这 200 行是当时唯一的选择。
但昨晚我突然意识到： 这些代码的保质期，可能只剩一年。
不是因为它们写错了，而是因为它们正在被模型和运行时从两端同时吞噬。
[Read More]上周，一个 FDE 给我发了条消息：「我让 Agent 帮我做一份竞品分析，它说『好的，我开始处理』，然后就消失了。两个小时后我实在忍不住，去群里问『你还在跑吗』，它回了句『是的，还在处理中』。又过了半小时，终于出来了——结果质量不错，但这两个半小时里我完全不知道它在干嘛、做到哪了、有没有卡住。」
这个场景太常见了。而且它暴露了一个大多数 Agent 平台都没认真对待的问题： 长程任务的人机交互设计。
不是模型能力的问题，不是工具调用的问题——是 通信协议 的问题。Agent 和人之间，缺少一套关于「什么时候说话、说什么、怎么说」的共识。
[Read More]上个月，一个做汽车零部件的客户给我看他们的数字员工矩阵。
七个 Agent，分布在不同的钉钉群里，覆盖销售跟进、采购审批、质检报告、供应商对账、项目进度追踪、会议纪要生成、新员工入职引导。每个 Agent 都有组织身份——有工号、有权限、有审批链、有审计日志。它们不是独立的聊天机器人，而是组织的一部分。
然后他问了一个让我想了很久的问题：「如果有人要换掉钉钉，这七个 Agent 能带走吗？」
答案是不能。不是技术上搬不走——代码和数据可以导出。而是这七个 Agent 的每一个都 深度嵌入 了钉钉的组织图谱：审批链上的层级关系、群里的权限配置、通讯录里的汇报线、上下游组织的合同状态。换一个平台，这些上下文全部归零。
这就是护城河。但它不是大多数人以为的那种护城河。
上个月，我去一个客户的运营部门看他们的周报流程。
过去的方式：周五下午，运营主管花两小时从三个系统里扒数据，手动填 Excel，写总结，发邮件给 VP。每周一早上开会讨论。
现在的方式：周一早上 8 点，数字员工「数据周报 Agent」自动从三个系统拉数据，生成周报，发到运营群里。主管花 10 分钟审核、批注，回复两个字：「OK」。
这看起来只是效率提升——从两小时变成 10 分钟。但仔细看，主语变了。
过去的周报流程，主语是 人：人去扒数据、人去写报告、人去发邮件。AI 最多是个辅助工具。
现在的周报流程，主语是 Agent：Agent 去拉数据、Agent 去生成报告、Agent 去发送。人变成了审核者和决策者。
这不是工具升级。这是工作流范式的迁移。
上个月和一个做制造业的客户聊。他们花了三个月，把内部的工艺参数、良率数据、供应商评分全部结构化，喂给了一个通用模型的 RAG 系统。效果确实好——Agent 回答的工艺问题比他们自己工程师还准，内部试用两周，业务部门已经开始依赖了。
然后 CTO 问了我一个问题：「如果我的竞品也买了同一个模型的 API，我的这些知识会不会变成模型的一部分，间接服务于他？」
我沉默了几秒。不是技术上做不到隔离——模型厂商的合同里确实写着不训练、不留存。但我没法告诉他怎么 验证 这一点。这是一个 信任问题，不是技术问题。
这个问题让我意识到：关于「模型和 Agent 的边界」的讨论，我们一直只从技术视角切入。但实际上，决定这条边界的不是能力，而是 数据主权。
[Read More]周五下午 4 点。你打开钉钉，你的 D 群里「本周的重点事项」消息已经发了 24 小时。16 位负责人被 @，每个人的进展回复散落在三个地方：有人私聊你说了三段话，有人在群里回了一个 emoji，还有人到现在一个字没发。
你要整理的，是一份让所有人都看得懂、能 action 的结构化进度报告。
手动做这件事需要 2-3 小时（经验估算）。你打开 16 个单聊窗口 + 群聊消息列表，翻来翻去。做得再仔细，也跑不掉三个 bias： recency bias ——最后看到的记得最清， salience bias ——写了一大段的人得到最多篇幅，写了三个字的人被一笔带过。 survivorship bias ——没回复的人直接消失在你的视野里，而不是被明确标记。
我手动做了这件事好几个月。然后写了一个 Agent Skill 文件——不到 200 行的 Markdown，把你的工作流程像岗位说明书一样写清楚。跑起来之后的效果不是「更快了」，而是 总结质量比手动好：每条来源可溯源、16 人全覆盖、没回复的标 ⚠️ 而不是消失。从 12 人扩到 16 人时，只改了 4 行映射表。
这篇文章讲的就是这个案例——以及如何把 Loop Engineering（让 Agent 自主跑到终点的工程方法）从写代码的场景，搬到管理协调的场景。
这个工程能落地，最关键的工具是 钉钉 DWS（DingTalk Workspace CLI）。DWS 是 Agent 与钉钉的统一接口层，它的设计让钉钉对 Agent 友好、对开发者友好。无论你使用哪款 Agent——OpenClaw、Hermes、OpenCode、悟空、MuleRun、WorkBuddy——都能通过 DWS 应用这套 AI 驱动的管理方法。Agent 是 fungible 的，接口层才是杠杆。
| 对比维度 | 手动汇总 | Agent Skill |
|---|---|---|
| 耗时 | 2-3 小时（经验估算） | Agent 运行约 10 分钟 + 人工审阅约 5 分钟（基于实际运行经验） |
| 覆盖率 | 高概率遗漏 1-3 人 | 16 人全覆盖，未回复显式标 ⚠️ |
| 可溯源性 | 凭记忆，无法定位原文 | 每条标注「单聊 MM-DD HH:MM」来源 |
| 扩展性 | 增加 4 人 = 多翻 4 个窗口 | 改 4 行映射表 |
| 一致性 | 受情绪/疲劳影响 | 相同输入 ≈ 相同输出 |
4 月底，OpenAI 发布了 Codex CLI 0.128.0。更新日志里藏着一句话：「Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls.」几乎同一时间，Claude Code 也上线了 /goal 指令。Greg Brockman 在推特上写了一句：「codex now has a built-in Ralph loop++.」
大多数人把这条更新当作又一个 feature flag 滑过去了。但如果你仔细拆解 /goal 的设计，会发现它代表的不是「又一个功能」，而是 AI Agent 工程的一次范式跃迁。
知识管理有四个值得做的企业场景，其中「企业 SOP / 最佳实践沉淀」看起来最不起眼——知识静态、更新慢、容易退化成高级搜索、用户日活偏弱。
但如果你换一个角度看，SOP 沉淀的真正价值不是「把经验存起来」，而是 把经验变成可执行的系统行为。
这篇文章用一个完整案例来说明：一位 Windows 用户打开悟空发起任务，悟空报错「任务执行环境准备失败」，到 AI 定位根因、修复代码、验证、发布，全程 4 小时。每个环节 AI 做什么、人做什么、知识如何在这个过程中自然沉淀。
[Read More]