有 Mermaid 和 Structurizr 还不够吗？Birdview 在 AI Coding 中补上了什么
2026/9/23 11:37:02
很多团队把 AI Agent 接进企业微信后碰到的同一个尴尬：助手能聊天、能查信息、能发消息，但客户说"帮我处理一下昨天那个订单的问题"时，助手还是只能回"已为您转接人工"。问题不在模型，在于助手还没有真正"被授权"执行企业任务——它能调 Eyun 平台的接口发消息、查客户，但企业的核心业务系统（CRM、ERP、订单、财务）对它来说是封闭的。这篇聊怎么把 AI Agent 和企业真实任务对接，让它真的能"办事"，而不只是"传话"。
一、企业任务和聊天任务的本质差异
先理清边界，避免概念模糊：
维度 | 聊天任务 | 企业任务 |
|---|---|---|
完成标准 | 客户收到回复 | 业务系统状态变更 |
工具范围 | Eyun 平台 API | 企微 + 业务系统 API |
失败代价 | 客户再问一次 | 业务数据错误、流程混乱 |
责任追溯 | 聊天记录即可 | 审计日志 + 业务变更链路 |
权限要求 | 通用 | 按角色严格授权 |
差异决定设计：企业任务执行必须有更严的工具管理、更细的权限控制、更完整的审计。不能让 Agent 像"调 sendText 一样"地调"修改订单金额"接口。
二、任务定义：把模糊需求变成可执行任务
客户或员工给助手的指令经常是模糊的："帮我处理下昨天那个订单的问题"。助手要做的第一件事是把模糊指令变成可执行任务定义：
目标识别：客户想达成什么——退款？换货？催办？
对象识别：哪个订单？哪个客户？
上下文补全：客户最近互动过的订单是哪个？最近投诉的是哪个？
目标识别靠 LLM 理解，对象识别要调查询接口（按客户ID查最近订单、查进行中工单），上下文补全要查会话历史和客户行为。这三步循环跑完，模糊的"处理昨天那个订单的问题"变成具体的"为客户 A 处理订单 SO-12345 的退款申请"。
任务定义的输出是结构化的：
{ "taskType": "refund_process", "targetCustomer": "uin_xxx", "orderId": "SO-12345", "goal": "完成退款申请并通知客户", "constraints": ["退款金额需人工审批", "客户拒绝即停止"] }这个结构化任务定义是后续执行引擎的输入。任务定义错了后面全错，所以这一步要让模型反复确认——拿不准时主动反问客户"您说的订单是 SO-12345 吗"，不要瞎猜。
三、几个真实企业任务的端到端拆解
任务一：客户跟进任务
客户说"我上周问的那个产品再聊聊"。助手要做的：
识别意图：客户想继续之前的咨询
查客户最近咨询记录（调 CRM 接口）：找到上周咨询的是 A 产品
查 A 产品最新资料（调产品系统接口）：拿到当前价格、库存
查客户当前状态（调 Eyun 联系人接口）：确认仍是好友、当前归属销售
调 Eyun sendText 通知归属销售："客户 A 想继续聊 A 产品，请准备"
给客户回复："已通知您的专属顾问王经理，他会在 10 分钟内联系您"
整个任务跨越 Eyun、CRM、产品系统三个系统，调用 5 个接口，最终闭环。每个接口都需要 Agent 主动决策调用，而不是写死流程。
任务二：订单异常处理
物流系统报"订单 SO-12345 物流停滞 48 小时"。助手要做的：
接收业务系统事件（订单异常）
查订单详情（调订单系统接口）：客户、商品、发货地、目的地
查物流现状（调物流系统接口）：停滞原因、当前节点
判断严重程度（模型决策）：是否影响客户承诺时效
主动通知客户（调 Eyun sendText）："您的订单 SO-12345 因 XX 原因延迟，预计 2 天内送达"
创建内部工单（调工单系统接口）：标记物流异常、指派给物流跟进人
监控工单状态（定时任务）：工单解决后再次通知客户
这种任务传统做法是物流异常 → 客服批量查 → 客服一个个发消息。Agent 化之后是事件触发 → Agent 自主决策 → 自主执行 → 自主闭环，节省人力同时响应速度大幅提升。
任务三：跨部门协同
销售在企微里跟助手说"客户 A 想加速他的退款审批，金额 8000 元"。助手要做的：
识别意图：催办退款审批
查退款申请（调财务系统接口）：确认申请存在、当前审批节点、审批人
判断风险等级：金额 8000 元超过自主操作阈值（5000），需人工确认
起草通知内容，发给销售确认（调 Eyun sendText 给销售本人）
销售确认后，发通知给财务审批人（调内部 IM）
监控审批状态，审批完成后通知销售和客户
整个流程里 Agent 主动识别"金额超阈值需人工确认"，不会盲目地去催财务。这种人机协同节点是任务执行型 Agent 区别于全自动机器人的关键——会判断什么时候自己干、什么时候请示人。
任务四：运营报告生成
每天早上助手要给运营总监推送昨日运营总结。助手要做的：
定时任务触发（每天 9 点）
拉昨日数据：新增客户数、活跃客户数、消息总量、群发执行情况（调 Eyun 各接口）
拉业务数据：订单数、成交金额、退款数（调业务系统接口）
数据汇总和异常检测（模型分析）：识别异常波动
生成报告文本（模型生成）
发送报告（调 Eyun sendFile 发 PDF，或 sendRichText 发富文本）
这种任务不依赖客户触发，是 Agent 主动执行的内部任务。价值在于把运营每天要花 1 小时手动拉的报表自动化了。
四、人机协同节点设计
企业任务执行不可能完全无人，关键节点必须有人参与：
节点 | 触发条件 | 人做什么 |
|---|---|---|
任务确认 | 任务定义模糊或重要 | 确认任务目标 |
参数确认 | 涉及金额、合同、客户身份 | 确认具体参数 |
操作审批 | 高风险操作 | 审批通过或拒绝 |
异常处理 | Agent 决策失败 | 介入手动处理 |
结果确认 | 任务完成前 | 确认结果符合预期 |
这些节点的实现要做成对话式确认，而不是把人拉到另一个审批系统。Agent 通过 Eyun 消息接口发确认请求给相关人员，对方在企微里直接回复"同意""拒绝"或修改建议，Agent 接收后继续推进。整个协同过程发生在企微对话里，不用切换系统。
五、权限与审计
企业任务执行的权限要按角色 + 任务类型 + 操作对象三维控制：
角色：销售能催自己的退款、销售总监能催全团队、财务能改审批节点
任务类型：查询类自主执行、修改类需本人确认、删除类需主管审批
操作对象：客户 A 的数据 Agent 只能在客户 A 的范围内操作
每次工具调用都记审计日志：哪个 Agent、哪个任务、调了什么、传了什么参数、结果是什么、什么时候、谁授权。审计日志是事后追责和监管检查的唯一依据，不能省。
六、反馈学习：让 Agent 越用越准
Agent 上线不是终点，要持续学习：
成功任务的特征：模型自主完成的任务，把当时的目标理解、工具选择、参数填写都记录下来，作为正样本
失败任务的原因：转人工或客户投诉的任务，复盘是任务定义错、工具选错、参数错还是策略错
人工介入节点：哪些节点人工经常修改 Agent 的决策，说明 Agent 在这些点上不可信，要补规则或改 prompt
反馈学习不是简单"喂更多数据训模型"，是基于真实业务数据的策略迭代——工具描述、参数 schema、风险阈值、人机协同节点，都要按真实使用数据调。
七、部署节奏：从单任务试点到全业务覆盖
不要想着一次接通所有任务。推荐节奏：
单任务试点（1-2 个月）：选一个低风险、高频、边界清晰的任务（比如客户咨询查询）让 Agent 跑通，验证整套链路
任务族扩展（3-6 个月）：覆盖一个业务族的常见任务（比如客户服务族的所有查询和通知类任务）
跨业务族协同（6-12 个月）：开始做跨系统任务，比如订单异常自动处理、跨部门协同
主动型任务（12 个月后）：定时报告、主动运营、异常预警等 Agent 自主发起的任务
每一步稳定后再开放下一层。跳级上线等于让一个没实习过的新员工直接处理所有公司业务，事故必然频发。
写在最后
让 AI Agent 真正执行企业任务，不是接Eyun 平台 API这么简单——核心是把企业的业务系统、权限体系、审计要求、人机协同节点都按 Agent 能理解的方式暴露出来。Agent 的价值不在"会聊天"，在"会办事"。会办事的前提是企业的任务、工具、权限、审计这一整套基础设施就位。把这些做扎实，Agent 才能从"客服助手"升级成"业务执行者"，这才是企业微信二次开发的下一个台阶——把"客户问、人回答"升级成"客户说目标、Agent 去办"。