钉钉 AI 助理平台核心技术实践：从拟人化开发到 Agentic Workflows
企业软件在解决共性需求时游刃有余，但面对海量个性化定制往往成本高昂。随着大模型技术的爆发，智能化成为破局关键。然而，从炫酷的 AI 概念到真正可用的业务应用，横亘着巨大的鸿沟。本文将拆解钉钉 AI 助理平台的核心技术实践，探讨如何通过工程化手段让 AI 真正在企业场景中落地生根。
核心问题与挑战
将 AI 助理引入企业级应用，我们面临着四座大山：
- 定制成本高：To B 产品聚焦共性需求，而企业效率提升高度依赖个性化定制，传统开发模式成本极高。
- 可用性不足：大量 AI 应用停留在“聊一聊”或简单知识问答的层面，缺乏 360 度无死角的实用可用性，难以切入核心业务。
- 计算不稳定：LLM 擅长推理但不擅长精确计算，直接用大模型处理复杂业务逻辑极易出现幻觉和结果不可控。
- 接入痛点：传统 Webhook 接入方式要求暴露公网 IP、管理 TLS 证书及处理内网穿透，安全风险与开发门槛双高。
方案与实践
拟人化开发与 LUI/GUI 融合
为了降低定制门槛，开发模式必须演进。我们从全代码、低代码，走向了 Agent 拟人化开发。通过拟人化的 AI 助理连接企业的数字化底座（人、财、物）与业务场景，让流程定制像给助手派发任务一样简单。
在交互层面，纯粹的 LUI（自然语言交互）虽然灵活但存在模糊性，而纯粹的 GUI（图形界面）虽然确定却缺乏灵性。我们的解法是 LUI 与 GUI 融合，坚持实用性与确定性优先于概念创新。当 LUI 遇到模糊意图或需要精确输入时，无缝中断并唤起 GUI 组件（如日期选择器、搜索列表）进行确认，确保操作闭环的确定性。
技能打磨：大量工程，少量算法
AI 助理的能力取决于其掌握的技能，而技能打磨的核心原则是：不稳定的技能数量再多也是零。
以日程安排为例，LLM 负责理解“帮我明天下午拉一个两小时的会议”的意图，但具体的时间计算、冲突检测、人名匹配，必须交由工程代码执行。我们坚持“大量工程，少量算法”，只在 LLM 具备稳定优势的推理环节引入算法，其余精确计算环节全部用工程兜底。
在技能开发的具体实现上：
- 声明式 API 与 Grounding：采用兼容 OpenAPI Specification (OAS) 的声明式 API 设计，降低开发门槛。通过 Grounding 扩展机制（如
x-dingtalk-context），精准解决上下文注入、时间/人名实体识别以及不可伪造操作人身份的问题。 - Stream 模式替代 Webhook：全面升级为 Stream 模式接入，实现零公网 IP、零证书管理、零网关部署。彻底消除了公网暴露风险，将开发者从繁琐的底层网络配置中解放出来。
自定义 Planning、安全与多场域
面对复杂业务，单一的 Function Call 往往力不从心。我们类比自动驾驶架构，构建了 Agent 的感知-执行-算法引擎框架，并引入了自定义 Planning 机制：
- 快慢思考结合：针对准确性要求高的场景启用“慢思考”（多步推理验证），针对简单查询启用“快思考”（直通模式），在性能与准确性间取得平衡。
- 全链路可干预：提供全链路的 Planning 干预能力，开发者可以在推理、执行、反馈各环节插入硬性规则，避免 LLM 陷入死循环或偏离业务约束。
在安全与多端投放方面：
- 委托权限机制：AI 助理的权限严格限制在“用户授予助理的权限”与“用户自身权限”的交集内，确保助理代操作时绝不越权访问数据。
- 影子账号体系：为 AI 助理分配影子账号，使其能够在钉钉、微信、公众号等多端多场域中以统一的身份存在和运作，打破平台壁垒。
原则/方法论沉淀
在钉钉 AI 助理平台的实践中，我们沉淀出以下工程原则：
- 明确边界，实用优先：AI 应用必须有明确的能力边界，不画大饼，实用性与确定性永远优先于概念创新。
- 质量为王，不稳定即零：技能打磨不能只看数量，不稳定的技能对用户体验是毁灭性的，规模必须让步于质量。
- 大量工程，少量算法：认清 LLM 的能力边界，只在稳定推理环节引入算法，精确计算与业务校验交由工程解决。
- 权限交集，安全底线：AI 助理权限必须严格收敛于用户授权与系统权限的交集，守住企业数据安全红线。
总结与行动建议
企业软件正经历从信息化、数字化向智能化的演进，开发模式也从传统全代码走向 Agent 拟人化开发。未来的工作流将从人工硬编码编排，走向由 LLM 自动推理驱动的 Agentic Workflows。
行动建议：在当前阶段，不要盲目追求 AI 的全能，而是通过工程化手段为 LLM 兜底，打磨出 360 度可用的核心技能。利用声明式 API 与 Stream 模式降低接入成本，通过自定义 Planning 掌控复杂推理，逐步从工程化编排向智能化推理演进。
开放问题与延伸方向
- 声明式 API 与 Grounding 的兜底策略：当遇到未覆盖的模糊实体或跨系统指代时，系统是降级处理还是拒识？这直接关系到系统鲁棒性与用户体验的平衡。
- Stream 模式的高并发基准：零公网暴露的 Stream 长连接在极高并发下的保活容量，以及弱网环境下的重连容忍基准数据，是评估该架构生产可用性的关键。
- “重工程轻算法”的泛化隐忧：工程兜底保证了当前稳定性，但长期是否会陷入过度硬编码的泥潭，从而削弱 AI 本身的泛化红利？需警惕技术债务的积累。
- 影子账号的失控感与责任归属：用户是否会因“AI 代替我操作”产生失控感？出错时责任如何界定？这是产品信任度建设必须回答的问题。
- 自定义 Planning 的冲突死循环：全链路可干预带来极高运维成本，当硬性干预规则与 LLM 推理结果冲突时，系统如何避免死循环或决策瘫痪？干预框架需设定明确的熔断机制。
- LUI/GUI 融合的效率悖论：在层级极深或逻辑极复杂的业务流中，LUI 的模糊性是否会导致 GUI 的频繁打断，反而降低操作效率？需要界定 LUI 的适用边界。
- 委托权限的动态最小特权：权限交集机制能否进一步演化为动态的“最小特权凭证”，成为 B2B SaaS 在 AI 时代的数据安全新范式？极具行业推广价值。
- 快慢思考的边缘计算启发：快慢思考的 Planning 架构，为 Agent 在资源受限的边缘计算场景下，提供了关于计算卸载与响应优先级调度的有益启发。
- 替代 Stream 的轻量方案：除了长连接，基于零信任架构的反向代理或边缘节点中转，是否可作为解决 Webhook 公网暴露痛点的更轻量替代路径？
- 从拟人化到拟组织化：除了单 Agent 开发，是否可探索“拟组织化”的 Multi-Agent 协同，让不同 AI 助理模拟企业部门间的协作与审批？这指向了未来复杂业务流的解法。
- 向 Agentic Workflows 跨越的关键：从“重工程干预编排”向“自动推理”演进，最关键的跨越节点是底层模型推理能力的突破，还是工程干预框架的渐进式解耦？这决定了当前技术投资的侧重点。