钉钉工作区任务代理

为什么需要这个技能

当 Agent 需要处理钉钉业务时，团队常常为消息、文档、审批和工作区任务分别编写集成。每个集成都要重复处理认证、请求参数、对象 ID、返回结构、错误映射和状态续接。结果是逻辑分散、维护成本高，而且模型很难在多个入口之间保持一致。

如果企业已经具备 dingtalk-workspace-cli，更合理的做法是让 Agent 通过同一个 CLI surface 执行操作，而不是为每类动作再拼一套 API 调用。这个技能面向的就是这条路径。

它如何工作

• 先判断当前操作属于消息、文档、审批还是工作区任务，再选择对应能力范围。
• 以 dingtalk-workspace-cli 作为执行边界：Agent 负责理解目标、整理输入和解释结果，CLI 负责对接钉钉侧动作。
• 调用前显式传入必要参数；调用后从输出中提取 ID、标题、状态和错误信息。
• 多步工作流中，应使用前一步返回的标识进行后续操作，不要把文档 ID、审批实例 ID 或任务状态写死或凭空生成。
• 如果企业访问权限、组织授权或自定义应用凭据缺失，应把问题暴露为前置条件失败，而不是反复盲目重试。

适用边界与注意点

• 需要钉钉企业访问权限，以及组织授权或自定义应用凭据；个人账号或非企业场景不在覆盖范围内。
• 需要已有 Node.js 或 release binary，并已具备 dingtalk-workspace-cli；本技能是操作说明，不是安装器。
• 对发送消息、同意/驳回审批、修改文档、变更任务等有副作用的操作，执行前应核对目标对象、操作者、权限范围和最终影响。
• 组织权限、数据范围、限流和审计要求仍然存在；Agent 不应绕过钉钉后端的安全模型。
• 当 CLI 输出模糊或缺少关键标识时，应停止并请求澄清，不要猜测 ID 或伪造状态。