上个月和一个做制造业的客户聊。他们花了三个月，把内部的工艺参数、良率数据、供应商评分全部结构化，喂给了一个通用模型的 RAG 系统。效果确实好——Agent 回答的工艺问题比他们自己工程师还准，内部试用两周，业务部门已经开始依赖了。
然后 CTO 问了我一个问题：「如果我的竞品也买了同一个模型的 API，我的这些知识会不会变成模型的一部分，间接服务于他？」
我沉默了几秒。不是技术上做不到隔离——模型厂商的合同里确实写着不训练、不留存。但我没法告诉他怎么 验证 这一点。这是一个 信任问题，不是技术问题。
这个问题让我意识到：关于「模型和 Agent 的边界」的讨论，我们一直只从技术视角切入。但实际上，决定这条边界的不是能力，而是 数据主权。
[Read More]上个月，一个做消费品牌的朋友找我聊他们的 AI 项目。
他们花了三个月，让技术团队给 CEO 做了一个「数字分身」——能模仿 CEO 的语气给全员发周报、回答战略问题、甚至在新人培训里做公司介绍。演示那天，CEO 本人看了都觉得「挺像我的」。
然后他问了我一个问题：「这个东西，除了我自己觉得好玩，到底该给谁用？」
我说：你做了一个 分身，但你需要的是一个 员工。
他愣住了。
这不是个例。我观察到大量企业在启动 AI Agent 项目时，第一步就搞混了这两个概念——不是因为技术理解不够，而是因为 没有想清楚锚点在哪。
上周一个朋友跟我说，他们公司「上线了数字员工」。
我问：干了什么？
他说：在 HR 群加了个机器人，员工可以问请假政策、查工资条、提交报销。
我问：那和三年前上线的 FAQ 机器人有什么区别？
他愣了几秒：「……好像就多了个大模型，回答更像人话了。」
这不是段子。2026 年，钉钉、飞书、企业微信上跑着成千上万个「数字员工」，大多数落地形态惊人地相似： 一个大模型，挂在一个群里，回答预设范围内的问题。 换了个「数字员工」的名字，骨子里还是个聊天机器人。
真正的数字员工应该是什么样子？Anthropic 的 Claude Tag 给出了一个方向——Agent 以组织成员身份加入 Slack，有自己的记忆、权限和行为日志。我在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中详细分析过这个「身份层」的设计。
但身份只是第一步。把 Agent 的名字写进通讯录，工程量大概只占 10%。剩下的 90% 是什么？
周一早上，#platform-eng 频道。
Leo 发了一条消息：「checkout 今早变慢了，有人遇到吗？」
Dana 秒回：「我也是。」然后她 @了 Claude：「查一下今早部署的 diff，对比延迟数据，找出原因。」
接下来六分钟里发生的事，值得每个做 Agent 架构的人仔细看一遍。
9:02 Dana @Claude — Session 启动
9:02 Claude: "is thinking..." — 沙箱构建中
9:03 Claude 贴出 checklist:
✅ 拉 Datadog p99 延迟数据
✅ 对比 deploy 4f2c1 和 main 的 diff
⏳ 本地复现慢查询
⏳ 开 PR 修复
9:04 Sam 中途加入：「顺便查一下是不是和上周缓存改动有关？」
9:06 Claude: 已确认是 4f2c1 引入的 N+1 查询，PR #382 已开，CI 跑着
六分钟。从发现慢查询到 PR 开出。
[Read More]周一早上，运营群里有人 @了运营 Agent：「帮我看看上周退款率为什么涨了」。
Agent 开始干活。它先查了 AI 表格里的退款明细，又调了客服工单系统的投诉分类，接着跑了一段 SQL 算出各渠道的退款占比，最后生成一份带趋势图的分析报告发到群里。整个过程 40 分钟，中间还主动追问了一句：「要不要把退款金额 > 500 的单独拉出来？」
报告质量不错。但安全团队事后审计时发现了三个问题：
read:all，理论上 Agent 可以读任何人的工单。这是一个典型场景，我在不同企业里见过不同程度的版本。
在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中，我讨论了 Agent 为什么需要自己的身份。这篇接着往下走： 当 Agent 进入钉钉群，权限、凭证、审计这套架构具体怎么设计？
周一早上九点，小林到了客户的运营部。
他不是来做产品演示的，也不是来签合同的。他的工牌上写的是「Forward Deployed Engineer」——一个在钉钉内部新设立的岗位，外部还没有对应的职称。
上周客户提了一个需求：「每天有 20 个人整理会议纪要，能不能用 AI 提效？」
普通工程师听到这句话，想到的是做一个会议纪要工具。
小林想到的是：
会议
↓
纪要
↓
任务拆解
↓
责任人
↓
审批
↓
提醒
↓
知识沉淀
他要做的不是一个纪要工具，而是一个 会议 Agent。
上周，一个同事在工作群里 @了一个 AI Agent，让它分析最近 30 天的客户退款数据。Agent 查了 CRM、翻了工单、跑了 SQL，两小时后在群里贴出一份报告。
事后审计时，安全团队问了一个问题：
「这个操作，日志里记的是谁？」
答案是：那个 @Agent 的人。
但实际上，读数据的是 Agent，推理的是 Agent，写报告的是 Agent。人只是说了一句「帮我看看」。
这就是今天几乎所有企业 AI 产品的现状——Agent 没有身份。它在借用人的身份做事。
2026 年 6 月 23 日，Anthropic 发布了 Claude Tag——一个运行在 Slack 里的 AI Teammate。表面上看，它是又一个 Slack 集成。但如果你仔细看它的架构设计，会发现一件有意思的事：Anthropic 正在尝试解决一个行业里很少有人正面回答的问题——
[Read More]Agent 到底是谁？
AI 时代企业 IT 变革的主要方向，是把业务流程优化成由 AI 来驱动，减少原有流程中人力的投入。但上个月，一个做企业数字化的朋友跟我说：他们花了大半年把内部流程都接上了 AI，看起来每个环节都有 AI 参与，人力成本却几乎没降。员工还是在填表、还是在审批、还是在做报表，AI 只是在旁边多了一个「建议」按钮。
我问他：你们到底是在让 AI 帮忙做，还是让 AI 来做？
这两件事有本质区别。前者是给现有流程加一个 AI 助手，人的角色不变，AI 只是辅助。后者是围绕 AI 重新设计流程，让 AI 成为主执行者，人从执行者变成审核者和判断者。
老周是我们团队最资深的售前。上个月给华东一家汽配连锁分销商做方案，他熬了三个通宵，产出一份 80 页的 PPT —— 行业洞察、痛点拆解、架构图、ROI 测算、三个同行的成功案例，一应俱全。客户的财务总监当场说：「这是我见过最懂我们的方案。」单子签了。
四个月后，这个客户在续约评估里打了低分。原因不是产品不好，而是交付团队上线的对账流程，跟老周方案里承诺的「月结 T+1 出报告」对不上 —— 交付的同事根本没看过那份 PPT，他们手里只有一个工单：「给客户 A 部署对账 Agent」。老周写进方案的服务标准，卡在了销售和交付之间那道看不见的缝里。
而那份被财务总监称赞过的 80 页方案，此刻正安静地躺在某个钉盘文件夹里，再没有人打开过。
先讲一个我听来的真实教训。一位在某物流巨头做过数字化的朋友跟我说，他们曾经丢过一个大客户：销售签单时承诺了某条线路的时效和异常赔付标准，白纸黑字写在合同附件里。但这套承诺从来没有进过运营和售后的系统 —— 交付团队按通用 SOP 派单，时效标准对不上，出了几次异常也没按销售承诺的标准赔。三个月后客户怒而解约。产品没问题，销售没说谎，交付也尽力了，单子却死在了三者之间那道没人负责的缝里。
这不是个案。 销售到交付的断点，是企业里最贵、又最没人负责的一种成本 —— 它不在销售的 KPI 里（单子签了），不在交付的 KPI 里（工单做了），它只在客户续约时，以丢单的形式一次性结算。
