1. 从打卡工具到AI原生工作平台的定位跃迁钉钉这次把企业级AI原生工作平台这个定位抛出来我第一反应不是去看发布会通稿里那些漂亮话而是去翻它底层到底动了什么。因为AI原生这四个字在2024年之后已经被用烂了几乎每家大厂的产品更新都要挂上这个词但真正敢把原生两个字落到架构层面的没几个。钉钉这次的动作从关键词里能看出一些端倪——CLI、Agent、Token这三个词同时出现说明它想做的事情不是给现有产品加一个AI对话框而是把整个工作流的调度权交给Agent把交互入口从GUI往CLI方向挪。这个判断不是拍脑袋。你去看现在企业里真正高频使用钉钉的人群其实分两类一类是普通员工打卡、审批、看消息另一类是开发和运维团队他们用钉钉机器人做告警、做CI/CD通知、做内部工具集成。前一类用户对AI的需求是帮我写个周报帮我总结群消息后一类用户的需求是让Agent直接调我的接口把事办了。钉钉如果只做前者那它就是个套壳聊天助手只有把后者吃下来才配得上AI原生工作平台这个说法。而CLI和Agent恰恰是服务后一类用户的。陈航无招回归钉钉之后外界一直在猜他会怎么打这一仗。从这次发布的关键词组合看他的思路应该是不再跟飞书、企微在协同办公体验这个维度上缠斗而是直接换赛道把钉钉变成一个Agent的运行容器。这个判断背后有焦虑也有赌性。焦虑在于钉钉的用户增长早就见顶了DAU再怎么涨也就是那些企业客户内部的存量博弈赌性在于如果Agent真的成为企业软件的新交互范式那谁先把自己的平台变成Agent的操作系统谁就能吃到下一波红利。我个人的观察是这次发布里最值得琢磨的不是那些演示Demo而是CLI这个词被放到了和Agent并列的位置。为什么因为CLI意味着可脚本化、可编排、可被其他程序调用。一个平台如果只提供GUI那它的AI能力就只能被人类手动触发一旦它提供CLIAgent就可以把它当成一个工具来调用。这是从人用AI到AI用平台的分水岭。钉钉把CLI抬到这个位置说明它想做的不是给钉钉加AI而是让钉钉成为AI的手脚。1.1 为什么是CLI而不是API很多人会问要做Agent集成提供API不就行了吗为什么非要强调CLI这个问题我在做内部工具集成的时候踩过坑值得展开说。API是给程序调用的CLI是给人和程序都能调用的。这两者的区别在于可发现性和可组合性。一个REST API你得先读文档、知道endpoint、构造请求、处理鉴权才能调通。而一个设计良好的CLI你敲一个--help就能看到所有能力敲一个命令就能跑通还能用管道和其他命令组合。对于Agent来说CLI的友好度远高于API因为Agent的思考过程本质上是在生成命令序列而不是在构造HTTP请求。更关键的是CLI天然适合做权限隔离和审计。企业级场景里你不可能让一个Agent拿着一个万能Token去调所有API但你可以给它一个受限的CLI环境它只能执行白名单里的命令。钉钉如果真把CLI做扎实了那企业IT部门就可以用一套统一的策略来管理哪些Agent能调哪些钉钉能力这比给每个Agent发一套API Key要可控得多。提示如果你所在团队正在做内部Agent平台优先给核心系统封装CLI而不是裸API后期做权限和审计会省掉大量返工。1.2 Token在这个架构里扮演什么角色热词里Token出现的频率极高而且很多是和token失效token exchange failed这类报错绑在一起的。这说明什么说明现在大量开发者正在做Agent和外部服务的对接而Token管理是这条链路上最容易出问题的一环。在钉钉这个AI原生平台的语境下Token至少承担三个职责身份凭证、配额计量、能力授权。身份凭证好理解就是证明这个Agent代表哪个用户/哪个应用配额计量是AI时代的新需求因为Agent调用大模型是要烧钱的企业必须能按Token用量来核算成本能力授权则是说不同的Token对应不同的能力边界比如一个只读Token不能触发审批流。我见过太多团队在Token设计上偷懒用一个长期不过期的万能Token打通所有环节结果一出事就是全链路沦陷。钉钉如果要在企业级市场站住脚Token体系必须是细粒度、可撤销、可审计的。这也是为什么热词里jwt实现token续签token失效这类问题被反复搜索——大家在实际落地时都被这个问题卡过。2. Agent开发者在钉钉生态里能拿到什么抛开战略层面的分析落到实操层面一个做Agent开发的团队最关心的是钉钉这个平台能给我提供什么我需要付出什么。我从关键词里挑几个和开发直接相关的点来拆。2.1 Agent的接入方式和运行边界从agent沙盒agent安全agent架构这些热词看大家最焦虑的是Agent跑起来之后怎么管。钉钉如果提供Agent托管能力那它必须回答几个问题Agent跑在谁的机器上能访问哪些数据出错了怎么回滚我的判断是钉钉大概率会走沙盒能力声明的路线。也就是说你开发一个Agent需要在一个声明文件里写清楚它要调用哪些钉钉能力比如读通讯录、发消息、查审批单平台在运行时按这个声明来放行或拦截。这个模式和现在主流的Agent框架比如一些开源Agent框架里的tool permission机制是一致的。对开发者来说这意味着你不能像以前写脚本那样想调什么调什么而是要提前把能力清单列清楚。好处是安全可控坏处是灵活性下降。我的经验是在早期就把能力声明做得细一点别图省事写个全部权限否则后期做安全审计时会被打回重做。2.2 CLI工具链的安装与配置热词里codex cli安装gitlab cli安装trae clizcode cli这些词扎堆出现说明现在开发者对CLI工具的接受度已经很高了。钉钉如果推出自己的CLI安装和配置体验会直接决定它的推广速度。一个企业级CLI工具的安装通常要考虑三种场景个人开发机、CI/CD流水线、内网离线环境。个人开发机好办一条安装命令搞定CI/CD流水线需要支持非交互式登录也就是用Token而不是用浏览器扫码内网离线环境最麻烦需要提供离线安装包和私有源配置。注意企业内网环境往往没有外网访问权限CLI工具如果强依赖在线鉴权在离线环境里会直接不可用。选型时务必确认它支持离线模式或私有化部署。我踩过的一个坑是某CLI工具在登录时会去请求一个外部鉴权服务内网机器根本连不上报了一堆token exchange failed的错。后来只能放弃改用支持私有化鉴权的方案。所以钉钉的CLI如果要进企业内网离线鉴权能力是必选项不是加分项。2.3 Agent扛并发这件事平台该负多少责ai agent 怎么扛并发这个热词很真实。Agent和传统API不一样它的单次调用可能涉及多轮模型推理、多次工具调用耗时可能是秒级甚至分钟级。如果平台不提供并发控制Agent一多就会互相抢资源。钉钉作为平台方至少应该提供三样东西请求队列、限流策略、超时熔断。请求队列保证Agent的调用不会因为瞬时高峰而丢失限流策略让企业可以按部门或按应用来分配配额超时熔断防止一个卡死的Agent拖垮整个系统。对开发者来说你不能指望平台把所有并发问题都解决掉。你自己的Agent逻辑里也要做幂等设计因为Agent重试是常态。我见过一个Agent因为没做幂等重试三次发了三条一样的审批通知直接把审批人搞烦了。3. 陈航回归与阿里的焦虑到底焦虑什么这部分我想说得直白一点。标题里焦虑两个字不是修辞是真实存在的。阿里的焦虑来自三个层面。第一个层面是入口焦虑。过去十年钉钉是阿里在企业服务领域的入口但这个入口的价值正在被稀释。企业微信靠着微信的社交关系链在抢客户飞书靠着字节的产品力在抢口碑钉钉夹在中间既没有微信的流量也没有飞书那种用起来真爽的体验。如果Agent成为新的企业软件入口那钉钉必须抢在别人之前把自己变成Agent的首选运行平台否则它连入口这个身份都保不住。第二个层面是技术焦虑。阿里在大模型上有通义系列但在Agent工程化这个层面它并没有明显的领先优势。Agent开发框架、工具调用协议、多Agent协作这些领域现在还是群雄混战的状态。钉钉如果不能在Agent工程化上做出差异化那它的大模型能力就只是又一个能聊天的AI落不到企业工作流里。第三个层面是组织焦虑。陈航回归本身就是一种信号说明阿里对钉钉之前的路线不满意。无招是钉钉的创始人他对这个产品的理解比任何人都深但他离开的这几年钉钉已经变成了一个庞大的组织重新掌舵能不能把方向掰过来是个未知数。这次发布AI原生工作平台可以看作是他给出的第一份答卷。3.1 从打卡到Agent用户心智的迁移成本热词里钉钉打卡虚拟定位钉钉定位这些词还在被搜索说明大量用户对钉钉的认知还停留在打卡工具这个层面。这个心智认知是钉钉做AI原生平台最大的障碍。你想想一个员工每天打开钉钉是为了打卡、看消息、走审批你突然告诉他这是一个AI原生工作平台他的反应大概率是哦然后呢。心智迁移不是靠发布会能完成的得靠实际使用场景的渗透。比如当员工发现我可以用自然语言让钉钉帮我发起一个跨部门审批它自动填好了所有字段他才会真正感知到AI原生的价值。对开发者来说这意味着你在钉钉上做Agent要优先选那些高频、刚需、现有流程很繁琐的场景。别一上来就做AI帮你写周报这种锦上添花的东西先做AI帮你把报销单填了这种雪中送炭的。3.2 企业级市场的付费逻辑和消费级完全不同阿里做消费级产品很擅长但企业级市场的付费逻辑是另一套。消费级看DAU、看时长、看转化企业级看ROI、看合规、看集成成本。钉钉推AI原生平台企业客户第一个问题不会是这个AI有多聪明而是它能帮我省多少人、省多少钱、出了事谁负责。所以钉钉在商业化上必须给出清晰的计量方式——按Token用量计费、按Agent调用次数计费、还是按坐席数打包。这个计量方式直接决定了企业愿不愿意把核心流程交给它。我个人的经验是企业客户对按用量计费的接受度在提高但前提是账单要透明、可预测。如果月底突然收到一张天价Token账单那这个客户下个月就会跑。所以钉钉如果做Token计量必须提供预算告警和用量上限让企业能控制成本。4. 落地一个钉钉Agent的完整思路前面说了很多战略和判断这部分我想给一个更实操的视角。假设你现在要在钉钉上做一个Agent从零到跑通大概要经历哪些环节每个环节的坑在哪里。4.1 场景选择先找高频规则明确的切口不是所有场景都适合做Agent。我总结了一个简单的判断标准如果一个任务人类做的时候需要查三个系统、填五个字段、发两条通知那它就适合做Agent如果一个任务人类做的时候需要跟三个人扯皮、判断谁对谁错那它就不适合至少现在不适合。高频意味着有足够的调用量来摊薄开发成本规则明确意味着Agent的决策空间可控不容易出错。比如新员工入职自动开通账号并通知相关人就是一个好场景规则清晰、步骤固定、出错成本可控。而判断一个报销单该不该批就不是好场景因为它涉及主观判断和合规风险。4.2 能力声明把Agent的权限边界写死前面提过Agent的能力声明要细。具体怎么做我建议按资源操作两个维度来列。资源包括通讯录、审批单、日程、文档等操作包括读、写、删、执行。比如读通讯录和写通讯录是两个不同的权限不能合并。这样做的原因是Agent一旦被恶意利用或者出现逻辑错误它的破坏半径就被限制在声明的权限内。我见过一个Agent因为拿了写全部文档的权限结果在一个循环里把整个部门的文档都改了标题虽然最后恢复了但过程很吓人。提示能力声明文件建议纳入版本管理每次修改都要走代码评审避免有人图省事偷偷加权限。4.3 调试与可观测性Agent的黑盒问题Agent最难调试的地方在于它的行为不是确定性的。同样的输入可能因为模型推理的随机性而得到不同的输出。这就要求平台提供足够的可观测性——每一步推理的输入输出、每一次工具调用的参数和结果、每一个决策的分支路径都要能追溯。钉钉如果要做企业级Agent平台日志和追踪能力是核心竞争力之一。因为企业客户在出问题的时候第一反应是我要知道它为什么这么做而不是我要重新跑一遍。对开发者来说你在写Agent逻辑的时候要主动打日志尤其是关键决策点。别指望平台的默认日志能覆盖你的业务逻辑那是不可能的。4.4 成本控制Token用量是新的服务器账单Agent跑起来之后Token消耗会成为一个持续的成本项。我建议在开发阶段就引入用量监控别等到上线后才发现账单失控。具体的做法是给每个Agent设置单次调用的Token上限超过就截断给每个用户或每个部门设置日/月用量配额超过就告警或限流定期分析用量分布找出那些消耗高但价值低的调用优化掉。我见过一个团队他们的Agent每次调用都会把整个知识库塞进上下文导致单次消耗极高。后来改成先做检索再塞相关片段成本直接降了八成。这种优化不需要多高深的技术但需要你有意识地去监控和分析。5. 热词背后的真实开发者困境把热词列表从头到尾看一遍你会发现一个很有意思的现象大量词条是关于报错和失败的。token exchange failedsign-in could not be completedfailed to refresh tokencodex无法发送消息——这些词扎堆出现说明现在做Agent开发的这批人正处在基础设施不完善的阵痛期。5.1 鉴权链路的脆弱性Agent要调用外部服务就要鉴权。而鉴权链路涉及多个环节本地凭证读取、Token刷新、服务端校验、权限匹配。任何一个环节出问题整个链路就断了。热词里jwt实现token续签cookie和session和token详解这些搜索反映的是开发者对鉴权机制的理解还不够扎实。很多人是半路出家做Agent之前没怎么接触过OAuth、JWT这些东西遇到Token过期就懵了。我的建议是在做Agent之前先把OAuth 2.0的几种授权模式搞清楚尤其是授权码模式和客户端凭证模式的区别。前者适合代表用户操作后者适合代表应用操作。选错了模式后面会一直别扭。5.2 沙盒与真实环境的差异显示更新agent沙盒这个热词说明很多开发者在沙盒里跑得好好的Agent一到真实环境就出问题。原因通常是沙盒里的数据和权限是简化过的真实环境要复杂得多。比如沙盒里通讯录只有十个人真实环境有十万人你的Agent如果做了全量遍历性能直接崩掉。再比如沙盒里的审批流只有两级真实环境有七级你的Agent如果假设了固定的审批层级逻辑就错了。所以我的经验是沙盒测试通过只是第一步一定要在真实环境的只读模式下再跑一遍确认数据量和流程复杂度不会把Agent搞崩。5.3 多Agent协作的坑agent框架agent架构agent是什么这些词说明很多人还在选型阶段。而harness和agent区别这个搜索特别有意思它反映的是开发者对Agent的边界在哪里这个问题还没想清楚。我的理解是Agent是能自主决策并调用工具完成任务的实体而harness是约束和引导Agent行为的框架。前者是演员后者是导演。你在设计系统的时候要先想清楚哪些决策交给Agent哪些决策由harness固定死。全交给Agent系统会失控全交给harness那Agent就退化成了一个普通的工作流引擎。这个平衡点怎么找我的经验是把需要判断但判断错了后果可控的环节交给Agent把不需要判断或者判断错了后果严重的环节交给harness。比如选择用哪个模板发通知可以交给Agent决定通知发给谁最好由harness根据规则确定。6. 我对这个平台后续走向的几个判断写到这里我想给出几个偏个人的判断不一定对但都是我基于一线观察得出的。第一个判断钉钉的AI原生平台短期内最大的竞争对手不是飞书或企微而是企业自己内部搭建的Agent平台。很多有技术实力的公司已经在用开源框架自己搭Agent系统了他们不需要钉钉来提供这个能力。钉钉要争取的是那些想做Agent但没有技术团队的中小企业。所以它的产品设计必须足够傻瓜化开箱即用而不是给开发者一堆SDK让他们自己拼。第二个判断CLI会成为一个被低估的入口。现在大家都在卷GUI里的AI对话框但真正高频、真正能沉淀工作流的是CLI。因为CLI可以被脚本化、可以被CI/CD集成、可以被其他Agent调用。钉钉如果能把CLI做扎实它就能渗透到那些不用钉钉GUI但用钉钉CLI的开发场景里这是一个被忽视的增量市场。第三个判断Token经济会成为平台的核心商业模式。当Agent调用成为常态Token就是新的水电煤。平台方通过控制Token的发行、计量、结算就能掌握整个生态的定价权。这也是为什么钉钉要在Token体系上投入这么多——它不只是个技术问题更是个商业问题。最后说一个我自己的体会。做Agent这件事技术只是一半另一半是对业务的理解。我见过太多技术很牛但业务理解很浅的Agent做出来没人用。钉钉这个平台能帮你解决技术那一半但业务那一半还是得你自己下场去摸。别指望平台能替你想清楚这个Agent到底解决谁的什么问题这个问题只有你能回答。
1. 从打卡工具到AI原生工作平台的定位跃迁钉钉这次把企业级AI原生工作平台这个定位抛出来我第一反应不是去看发布会通稿里那些漂亮话而是去翻它底层到底动了什么。因为AI原生这四个字在2024年之后已经被用烂了几乎每家大厂的产品更新都要挂上这个词但真正敢把原生两个字落到架构层面的没几个。钉钉这次的动作从关键词里能看出一些端倪——CLI、Agent、Token这三个词同时出现说明它想做的事情不是给现有产品加一个AI对话框而是把整个工作流的调度权交给Agent把交互入口从GUI往CLI方向挪。这个判断不是拍脑袋。你去看现在企业里真正高频使用钉钉的人群其实分两类一类是普通员工打卡、审批、看消息另一类是开发和运维团队他们用钉钉机器人做告警、做CI/CD通知、做内部工具集成。前一类用户对AI的需求是帮我写个周报帮我总结群消息后一类用户的需求是让Agent直接调我的接口把事办了。钉钉如果只做前者那它就是个套壳聊天助手只有把后者吃下来才配得上AI原生工作平台这个说法。而CLI和Agent恰恰是服务后一类用户的。陈航无招回归钉钉之后外界一直在猜他会怎么打这一仗。从这次发布的关键词组合看他的思路应该是不再跟飞书、企微在协同办公体验这个维度上缠斗而是直接换赛道把钉钉变成一个Agent的运行容器。这个判断背后有焦虑也有赌性。焦虑在于钉钉的用户增长早就见顶了DAU再怎么涨也就是那些企业客户内部的存量博弈赌性在于如果Agent真的成为企业软件的新交互范式那谁先把自己的平台变成Agent的操作系统谁就能吃到下一波红利。我个人的观察是这次发布里最值得琢磨的不是那些演示Demo而是CLI这个词被放到了和Agent并列的位置。为什么因为CLI意味着可脚本化、可编排、可被其他程序调用。一个平台如果只提供GUI那它的AI能力就只能被人类手动触发一旦它提供CLIAgent就可以把它当成一个工具来调用。这是从人用AI到AI用平台的分水岭。钉钉把CLI抬到这个位置说明它想做的不是给钉钉加AI而是让钉钉成为AI的手脚。1.1 为什么是CLI而不是API很多人会问要做Agent集成提供API不就行了吗为什么非要强调CLI这个问题我在做内部工具集成的时候踩过坑值得展开说。API是给程序调用的CLI是给人和程序都能调用的。这两者的区别在于可发现性和可组合性。一个REST API你得先读文档、知道endpoint、构造请求、处理鉴权才能调通。而一个设计良好的CLI你敲一个--help就能看到所有能力敲一个命令就能跑通还能用管道和其他命令组合。对于Agent来说CLI的友好度远高于API因为Agent的思考过程本质上是在生成命令序列而不是在构造HTTP请求。更关键的是CLI天然适合做权限隔离和审计。企业级场景里你不可能让一个Agent拿着一个万能Token去调所有API但你可以给它一个受限的CLI环境它只能执行白名单里的命令。钉钉如果真把CLI做扎实了那企业IT部门就可以用一套统一的策略来管理哪些Agent能调哪些钉钉能力这比给每个Agent发一套API Key要可控得多。提示如果你所在团队正在做内部Agent平台优先给核心系统封装CLI而不是裸API后期做权限和审计会省掉大量返工。1.2 Token在这个架构里扮演什么角色热词里Token出现的频率极高而且很多是和token失效token exchange failed这类报错绑在一起的。这说明什么说明现在大量开发者正在做Agent和外部服务的对接而Token管理是这条链路上最容易出问题的一环。在钉钉这个AI原生平台的语境下Token至少承担三个职责身份凭证、配额计量、能力授权。身份凭证好理解就是证明这个Agent代表哪个用户/哪个应用配额计量是AI时代的新需求因为Agent调用大模型是要烧钱的企业必须能按Token用量来核算成本能力授权则是说不同的Token对应不同的能力边界比如一个只读Token不能触发审批流。我见过太多团队在Token设计上偷懒用一个长期不过期的万能Token打通所有环节结果一出事就是全链路沦陷。钉钉如果要在企业级市场站住脚Token体系必须是细粒度、可撤销、可审计的。这也是为什么热词里jwt实现token续签token失效这类问题被反复搜索——大家在实际落地时都被这个问题卡过。2. Agent开发者在钉钉生态里能拿到什么抛开战略层面的分析落到实操层面一个做Agent开发的团队最关心的是钉钉这个平台能给我提供什么我需要付出什么。我从关键词里挑几个和开发直接相关的点来拆。2.1 Agent的接入方式和运行边界从agent沙盒agent安全agent架构这些热词看大家最焦虑的是Agent跑起来之后怎么管。钉钉如果提供Agent托管能力那它必须回答几个问题Agent跑在谁的机器上能访问哪些数据出错了怎么回滚我的判断是钉钉大概率会走沙盒能力声明的路线。也就是说你开发一个Agent需要在一个声明文件里写清楚它要调用哪些钉钉能力比如读通讯录、发消息、查审批单平台在运行时按这个声明来放行或拦截。这个模式和现在主流的Agent框架比如一些开源Agent框架里的tool permission机制是一致的。对开发者来说这意味着你不能像以前写脚本那样想调什么调什么而是要提前把能力清单列清楚。好处是安全可控坏处是灵活性下降。我的经验是在早期就把能力声明做得细一点别图省事写个全部权限否则后期做安全审计时会被打回重做。2.2 CLI工具链的安装与配置热词里codex cli安装gitlab cli安装trae clizcode cli这些词扎堆出现说明现在开发者对CLI工具的接受度已经很高了。钉钉如果推出自己的CLI安装和配置体验会直接决定它的推广速度。一个企业级CLI工具的安装通常要考虑三种场景个人开发机、CI/CD流水线、内网离线环境。个人开发机好办一条安装命令搞定CI/CD流水线需要支持非交互式登录也就是用Token而不是用浏览器扫码内网离线环境最麻烦需要提供离线安装包和私有源配置。注意企业内网环境往往没有外网访问权限CLI工具如果强依赖在线鉴权在离线环境里会直接不可用。选型时务必确认它支持离线模式或私有化部署。我踩过的一个坑是某CLI工具在登录时会去请求一个外部鉴权服务内网机器根本连不上报了一堆token exchange failed的错。后来只能放弃改用支持私有化鉴权的方案。所以钉钉的CLI如果要进企业内网离线鉴权能力是必选项不是加分项。2.3 Agent扛并发这件事平台该负多少责ai agent 怎么扛并发这个热词很真实。Agent和传统API不一样它的单次调用可能涉及多轮模型推理、多次工具调用耗时可能是秒级甚至分钟级。如果平台不提供并发控制Agent一多就会互相抢资源。钉钉作为平台方至少应该提供三样东西请求队列、限流策略、超时熔断。请求队列保证Agent的调用不会因为瞬时高峰而丢失限流策略让企业可以按部门或按应用来分配配额超时熔断防止一个卡死的Agent拖垮整个系统。对开发者来说你不能指望平台把所有并发问题都解决掉。你自己的Agent逻辑里也要做幂等设计因为Agent重试是常态。我见过一个Agent因为没做幂等重试三次发了三条一样的审批通知直接把审批人搞烦了。3. 陈航回归与阿里的焦虑到底焦虑什么这部分我想说得直白一点。标题里焦虑两个字不是修辞是真实存在的。阿里的焦虑来自三个层面。第一个层面是入口焦虑。过去十年钉钉是阿里在企业服务领域的入口但这个入口的价值正在被稀释。企业微信靠着微信的社交关系链在抢客户飞书靠着字节的产品力在抢口碑钉钉夹在中间既没有微信的流量也没有飞书那种用起来真爽的体验。如果Agent成为新的企业软件入口那钉钉必须抢在别人之前把自己变成Agent的首选运行平台否则它连入口这个身份都保不住。第二个层面是技术焦虑。阿里在大模型上有通义系列但在Agent工程化这个层面它并没有明显的领先优势。Agent开发框架、工具调用协议、多Agent协作这些领域现在还是群雄混战的状态。钉钉如果不能在Agent工程化上做出差异化那它的大模型能力就只是又一个能聊天的AI落不到企业工作流里。第三个层面是组织焦虑。陈航回归本身就是一种信号说明阿里对钉钉之前的路线不满意。无招是钉钉的创始人他对这个产品的理解比任何人都深但他离开的这几年钉钉已经变成了一个庞大的组织重新掌舵能不能把方向掰过来是个未知数。这次发布AI原生工作平台可以看作是他给出的第一份答卷。3.1 从打卡到Agent用户心智的迁移成本热词里钉钉打卡虚拟定位钉钉定位这些词还在被搜索说明大量用户对钉钉的认知还停留在打卡工具这个层面。这个心智认知是钉钉做AI原生平台最大的障碍。你想想一个员工每天打开钉钉是为了打卡、看消息、走审批你突然告诉他这是一个AI原生工作平台他的反应大概率是哦然后呢。心智迁移不是靠发布会能完成的得靠实际使用场景的渗透。比如当员工发现我可以用自然语言让钉钉帮我发起一个跨部门审批它自动填好了所有字段他才会真正感知到AI原生的价值。对开发者来说这意味着你在钉钉上做Agent要优先选那些高频、刚需、现有流程很繁琐的场景。别一上来就做AI帮你写周报这种锦上添花的东西先做AI帮你把报销单填了这种雪中送炭的。3.2 企业级市场的付费逻辑和消费级完全不同阿里做消费级产品很擅长但企业级市场的付费逻辑是另一套。消费级看DAU、看时长、看转化企业级看ROI、看合规、看集成成本。钉钉推AI原生平台企业客户第一个问题不会是这个AI有多聪明而是它能帮我省多少人、省多少钱、出了事谁负责。所以钉钉在商业化上必须给出清晰的计量方式——按Token用量计费、按Agent调用次数计费、还是按坐席数打包。这个计量方式直接决定了企业愿不愿意把核心流程交给它。我个人的经验是企业客户对按用量计费的接受度在提高但前提是账单要透明、可预测。如果月底突然收到一张天价Token账单那这个客户下个月就会跑。所以钉钉如果做Token计量必须提供预算告警和用量上限让企业能控制成本。4. 落地一个钉钉Agent的完整思路前面说了很多战略和判断这部分我想给一个更实操的视角。假设你现在要在钉钉上做一个Agent从零到跑通大概要经历哪些环节每个环节的坑在哪里。4.1 场景选择先找高频规则明确的切口不是所有场景都适合做Agent。我总结了一个简单的判断标准如果一个任务人类做的时候需要查三个系统、填五个字段、发两条通知那它就适合做Agent如果一个任务人类做的时候需要跟三个人扯皮、判断谁对谁错那它就不适合至少现在不适合。高频意味着有足够的调用量来摊薄开发成本规则明确意味着Agent的决策空间可控不容易出错。比如新员工入职自动开通账号并通知相关人就是一个好场景规则清晰、步骤固定、出错成本可控。而判断一个报销单该不该批就不是好场景因为它涉及主观判断和合规风险。4.2 能力声明把Agent的权限边界写死前面提过Agent的能力声明要细。具体怎么做我建议按资源操作两个维度来列。资源包括通讯录、审批单、日程、文档等操作包括读、写、删、执行。比如读通讯录和写通讯录是两个不同的权限不能合并。这样做的原因是Agent一旦被恶意利用或者出现逻辑错误它的破坏半径就被限制在声明的权限内。我见过一个Agent因为拿了写全部文档的权限结果在一个循环里把整个部门的文档都改了标题虽然最后恢复了但过程很吓人。提示能力声明文件建议纳入版本管理每次修改都要走代码评审避免有人图省事偷偷加权限。4.3 调试与可观测性Agent的黑盒问题Agent最难调试的地方在于它的行为不是确定性的。同样的输入可能因为模型推理的随机性而得到不同的输出。这就要求平台提供足够的可观测性——每一步推理的输入输出、每一次工具调用的参数和结果、每一个决策的分支路径都要能追溯。钉钉如果要做企业级Agent平台日志和追踪能力是核心竞争力之一。因为企业客户在出问题的时候第一反应是我要知道它为什么这么做而不是我要重新跑一遍。对开发者来说你在写Agent逻辑的时候要主动打日志尤其是关键决策点。别指望平台的默认日志能覆盖你的业务逻辑那是不可能的。4.4 成本控制Token用量是新的服务器账单Agent跑起来之后Token消耗会成为一个持续的成本项。我建议在开发阶段就引入用量监控别等到上线后才发现账单失控。具体的做法是给每个Agent设置单次调用的Token上限超过就截断给每个用户或每个部门设置日/月用量配额超过就告警或限流定期分析用量分布找出那些消耗高但价值低的调用优化掉。我见过一个团队他们的Agent每次调用都会把整个知识库塞进上下文导致单次消耗极高。后来改成先做检索再塞相关片段成本直接降了八成。这种优化不需要多高深的技术但需要你有意识地去监控和分析。5. 热词背后的真实开发者困境把热词列表从头到尾看一遍你会发现一个很有意思的现象大量词条是关于报错和失败的。token exchange failedsign-in could not be completedfailed to refresh tokencodex无法发送消息——这些词扎堆出现说明现在做Agent开发的这批人正处在基础设施不完善的阵痛期。5.1 鉴权链路的脆弱性Agent要调用外部服务就要鉴权。而鉴权链路涉及多个环节本地凭证读取、Token刷新、服务端校验、权限匹配。任何一个环节出问题整个链路就断了。热词里jwt实现token续签cookie和session和token详解这些搜索反映的是开发者对鉴权机制的理解还不够扎实。很多人是半路出家做Agent之前没怎么接触过OAuth、JWT这些东西遇到Token过期就懵了。我的建议是在做Agent之前先把OAuth 2.0的几种授权模式搞清楚尤其是授权码模式和客户端凭证模式的区别。前者适合代表用户操作后者适合代表应用操作。选错了模式后面会一直别扭。5.2 沙盒与真实环境的差异显示更新agent沙盒这个热词说明很多开发者在沙盒里跑得好好的Agent一到真实环境就出问题。原因通常是沙盒里的数据和权限是简化过的真实环境要复杂得多。比如沙盒里通讯录只有十个人真实环境有十万人你的Agent如果做了全量遍历性能直接崩掉。再比如沙盒里的审批流只有两级真实环境有七级你的Agent如果假设了固定的审批层级逻辑就错了。所以我的经验是沙盒测试通过只是第一步一定要在真实环境的只读模式下再跑一遍确认数据量和流程复杂度不会把Agent搞崩。5.3 多Agent协作的坑agent框架agent架构agent是什么这些词说明很多人还在选型阶段。而harness和agent区别这个搜索特别有意思它反映的是开发者对Agent的边界在哪里这个问题还没想清楚。我的理解是Agent是能自主决策并调用工具完成任务的实体而harness是约束和引导Agent行为的框架。前者是演员后者是导演。你在设计系统的时候要先想清楚哪些决策交给Agent哪些决策由harness固定死。全交给Agent系统会失控全交给harness那Agent就退化成了一个普通的工作流引擎。这个平衡点怎么找我的经验是把需要判断但判断错了后果可控的环节交给Agent把不需要判断或者判断错了后果严重的环节交给harness。比如选择用哪个模板发通知可以交给Agent决定通知发给谁最好由harness根据规则确定。6. 我对这个平台后续走向的几个判断写到这里我想给出几个偏个人的判断不一定对但都是我基于一线观察得出的。第一个判断钉钉的AI原生平台短期内最大的竞争对手不是飞书或企微而是企业自己内部搭建的Agent平台。很多有技术实力的公司已经在用开源框架自己搭Agent系统了他们不需要钉钉来提供这个能力。钉钉要争取的是那些想做Agent但没有技术团队的中小企业。所以它的产品设计必须足够傻瓜化开箱即用而不是给开发者一堆SDK让他们自己拼。第二个判断CLI会成为一个被低估的入口。现在大家都在卷GUI里的AI对话框但真正高频、真正能沉淀工作流的是CLI。因为CLI可以被脚本化、可以被CI/CD集成、可以被其他Agent调用。钉钉如果能把CLI做扎实它就能渗透到那些不用钉钉GUI但用钉钉CLI的开发场景里这是一个被忽视的增量市场。第三个判断Token经济会成为平台的核心商业模式。当Agent调用成为常态Token就是新的水电煤。平台方通过控制Token的发行、计量、结算就能掌握整个生态的定价权。这也是为什么钉钉要在Token体系上投入这么多——它不只是个技术问题更是个商业问题。最后说一个我自己的体会。做Agent这件事技术只是一半另一半是对业务的理解。我见过太多技术很牛但业务理解很浅的Agent做出来没人用。钉钉这个平台能帮你解决技术那一半但业务那一半还是得你自己下场去摸。别指望平台能替你想清楚这个Agent到底解决谁的什么问题这个问题只有你能回答。
