干过 D365 落地的人应该都有同感前两年大家还在比谁的提示词写得更花哨现在风向已经变了。提示词写得再漂亮最多也就是生成一段看起来很专业的文案但客户投诉还是没有分派商机跟进还是没人做库存缺料还是没人通知。Agentic AI 在 D365 里的价值不是让对话更聪明而是让模型把提示词理解成一套可执行的行动计划然后真正调用 API、操作业务记录、触发流程把一件事从头做到尾。这篇文章想聊的就是这条从提示词到自动执行的落地路径适合正在做 D365 实施、售前架构或者准备在项目里引入 AI Agent 的团队参考。1. Agentic AI 和传统提示词的分水岭从“生成建议”到“产生结果”1.1 提示词的局限内容产出不等于业务闭环先给一个很常见的画面。某分销企业的客服主管每天让智能助手帮忙汇总客户投诉助手确实能输出一段总结问题分类、涉及产品、建议处理人。但接下来呢工单没有生成负责的销售没有收到通知问题记录没有写入系统。所有“建议”都停留在页面上最后还是有人手动复制粘贴手动建记录手动发消息。这不是提示词质量的问题而是交互模式的问题。传统提示词模式里模型是“顾问”人是“执行者”模型负责生成文本人负责把文本变成业务动作。Agentic AI 反过来模型是“执行者”人是“监督者”模型根据目标自己规划动作、调用工具、检查结果人只在关键节点确认。两者差别可以用一张表说清楚。对比项传统提示词模式Agentic AI 模式输出物文本、建议、摘要系统内可见的业务结果业务流程人来执行AI 辅助AI 执行人审批和监督核心能力语言理解和生成工具调用、任务规划、错误恢复失败处理重新生成提示词补偿操作、升级人工成功标准文本质量高业务数据正确、流程闭环1.2 Agentic 的三个判据我在项目里判断一套系统算不算 Agentic就看三个东西有没有明确目标有没有可用工具有没有反馈闭环。没有目标提示词就只能做单轮问答没有工具模型再聪明也改不了 D365 里的记录没有反馈闭环一次失败了就卡死根本谈不上“自动执行”。D365 恰好三个条件都具备。D365 本身业务对象丰富商机、订单、工单、库存、报价单都是现成的实体Web API、插件、自定义操作提供了大量工具入口审计日志、业务规则、状态流转又能给 Agent 提供执行反馈。可以说D365 是我见过最适合做 Agentic 落地的业务系统之一关键是你能不能把这套逻辑想清楚。1.3 为什么说 D365 是天然的 Agent 试验场很多系统也号称能做 Agent但落地时发现模型“有手难伸”。D365 的优势在于它的业务对象是被完整建模过的字段有类型记录有状态机权限有安全角色操作有插件事件。也就是说Agent 做每一步动作时系统知道这个动作是否合法、是否越权、是否影响下游流程。这种约束对 Agentic AI 不是坏事反而是保证可靠性的基础。2. 在 D365 里设计 Agent先搞清这四个运行要素2.1 指令层把业务流程写成 Agent 能执行的说明书很多人以为 Agent 的系统提示词就是把原来的业务提示词加几个“你可以调用工具”的字眼这是我在复盘时最容易踩的坑。Agent 的指令层应该像一份给新员工看的 SOP而不是一段营销文案。一份能落地的 Agent 指令至少包含五个部分角色和目标可用工具清单业务流程步骤边界条件与拒绝项异常处理方式。我这里给一个简化的模板。你是一个运行在 D365 环境中的业务执行代理。 当前业务目标处理销售团队提交的“商机跟进遗漏”任务。 可用工具 - query_opportunity查询商机基本信息与最近跟进记录 - create_task在 D365 中创建跟进任务 - send_email通过集成的邮件通道发送通知 - update_opportunity_status更新商机状态 执行规则 1. 先查询商机确认最近跟进时间是否超过 3 天 2. 超过 3 天则创建跟进任务负责人取商机所有者 3. 每一步动作前将动作、参数和预期结果写入执行日志 4. 如果查询结果为空或字段缺失停止执行并请求人工确认。这个模板看着简单但关键在于最后两条。让 Agent 把每一步动作写进执行日志是为了事后可以审计让 Agent 在数据不完整时停下来是为了防止它拿着空数据继续胡编乱造。2.2 工具层从 Web API 到插件的能力边界工具层是 Agentic 落地里工作量最大的一块。理论上D365 能暴露成工具的能力非常多实体的增删改查、执行工作流、调用自定义操作、查询视图数据、发送邮件与通知。但实际落地时不能把这些接口一股脑丢给模型。我的做法是把 D365 能力分成三类。第一类是查询类工具比如按条件检索商机、读取库存数量这类工具风险低可以让 Agent 自由调用第二类是创建类工具比如建工单、建任务、生成报价单这类工具会影响数据最好设置人工确认点第三类是状态变更类工具比如关闭订单、取消合同这类工具不可逆或影响面大默认不开放除非单独授权。每次工具调用D365 都会产生插件触发、字段更新、关联记录变化。所以在设计工具层时我建议每个工具都要定义清楚入参校验规则、预期业务影响、可能触发的插件、失败时的补偿动作。工具不是越粗越好也不是越细越好而是要和业务负责人的风险偏好匹配。2.3 上下文层会话记忆、业务数据和规则的叠加Agent 在 D365 里执行任务光有“当前对话”是不够的。比如用户说“帮我处理这张订单”Agent 必须知道“这张订单”指的是哪一条记录、这个客户有什么信用额度、这个产品有没有库存。这些上下文不会自己跑进模型里需要你主动装配。在实践中我通常把上下文拆成三层。第一层是会话上下文记录用户本次交互的目的和历史动作第二层是实体上下文通过查询获取订单、商机、客户等记录的关键字段第三层是规则上下文比如信用审批阈值、库存安全线、节假日日历等业务约束。这里有个容易被忽略的点上下文不是越多越好。把整张订单的全部字段塞给模型既浪费 token又容易让模型忽略关键字段。我的经验是只给模型喂它“做决定”必需的信息其余字段在工具调用时按需再取。2.4 执行与回滚自动操作最怕“做一半”自动执行的底色是可靠性和可恢复性。D365 的插件机制里一次操作可能在创建主记录后触发关联插件如果后面某一步失败前面的已生效改动要不要回退这类问题在人工操作时很好处理人自己知道刚才点了什么但在 Agent 自动执行时如果没设计好幂等和补偿就会留下一堆半成品数据。一个典型的例子是创建“销售订单订单明细”两步操作。如果订单头建好了明细写入时失败Agent 重试第二次就可能产生重复订单头。解决办法是让创建工具支持幂等键用业务编号或 GUID 作为唯一标识创建前先按标识查一遍存在则不重复创建。这个思路和集成对接里防重是一致的只不过现在是 Agent 在替你做这个决策。3. 从提示词到自动执行的架构我反复验证的三段式流水线3.1 第一段意图拆解与任务规划Agentic 流程的第一步是让模型把用户的一句话拆成结构化任务列表。这一段的核心不是执行而是“想清楚要干什么”。比如用户输入“客户 A 的商机快超期了帮我跟进一下”模型不能直接去发邮件而是要规划出查询客户 A 的商机、核对最近跟进日期、判断是否超期、决定是否创建任务或发提醒。实现上这一段建议让模型的输出是严格 JSON 格式的动作序列而不是自然语言。我常用的一种规划结果如下。{ intent: 跟进超期商机, confidence: 0.82, required_approval: false, plan: [ {tool: query_opportunity, args: {account_name: 客户A, status: 活跃}}, {tool: check_last_follow_up, args: {}}, {tool: create_task, args: {task_type: 跟进, owner_auto: true}} ] }这里让模型输出required_approval和confidence字段非常重要。当模型对意图判断不自信或者动作涉及不可逆操作时系统可以自动进入人工确认分支。这个设计比让模型自己“感觉有问题就说一声”可靠得多因为它是结构化的、可被代码控制的。3.2 第二段工具调用与执行验证规划只是纸面计划真正执行时要解决两个问题参数怎么来结果怎么验。很多初版 Agent 失败在参数阶段——模型规划时要查“客户 A”但它只知道“客户 A”这个名字不知道 D365 里这条记录的 GUID。因此执行引擎需要在调用前做参数补全把自然语言名称映射到系统内的唯一标识。验证也不可少。每调用完一个工具Agent 要判断结果是否符合预期。比如调用query_opportunity后返回的商机数量是 0那说明这个客户可能没有活跃商机后续的create_task就不应该执行了。我一般要求执行引擎维护一个小的状态机每个工具定义“成功条件”和“失败分支”而不是让模型自己临场发挥。3.3 第三段结果回写与人工兜底自动执行的最后一段不是“完成”而是“结果可被确认”。Agent 完成后应该在 D365 里留下可查的证据创建了什么记录、改了哪些字段、调用了哪些工具、整个过程的 trace_id 是什么。这些信息既给审计用也给业务用户铺一条“反悔”的路。人工兜底有两种实现。一种是在动作执行前设置审批点Agent 把待执行动作推给业务负责人负责人确认后才继续另一种是在执行后设置观察窗Agent 先执行低风险动作但高风险动作比如发送对外邮件、修改价格要等待人工批准。我建议从第二种开始因为它的自动化程度更高也更贴近 Agentic 的“自动执行”目标。3.4 一个最小可运行的 Agent 执行循环把三段连起来本质是一个循环。我写过一个很粗糙但足够说明问题的伪代码思路是有未完成任务就规划下一步需要批准就中断执行失败就回滚或升级。while pending_tasks: next_step plan(goal, context) if next_step.requires_approval and not approved: request_confirmation(next_step) break result invoke_tool(next_step.tool, next_step.args) if validate_result(result): append_to_audit_log(next_step, result) update_context(result) else: compensate(next_step) escalate_to_human(trace_id) break这个循环看起来简单但它把“想”“做”“查”“补”四件事都覆盖了。实际生产环境里你还要加超时控制、并发限制、token 预算、工具调用次数上限等细节但先把这个循环跑通比一开始追求复杂架构更有价值。4. 三个典型场景怎么落地销售、客服、供应链的 Agent 打法4.1 销售场景商机超期提醒到自动创建跟进任务销售场景最常见的痛点是系统里有大量商机停在某个阶段没人管。传统做法是用报表筛出超期商机然后让销售自己去看Agentic 的做法是让 Agent 把“发现问题”和“解决问题”连起来。我在一个项目里跑过的流程是这样每天早上Agent 查询所有最近跟进日期超过 3 天且阶段未变化的商机针对每条商机生成一句话摘要说明商机金额、已停留天数、建议下一步动作然后自动为商机负责人创建一条跟进任务并把摘要写入任务备注最后Agent 会给销售经理发一个汇总通知列出当天创建的跟进任务清单。这里很容易出问题的是“建议下一步动作”这一步。模型如果没有商机历史记录做上下文就会写出一堆“加强与客户沟通”之类的废话。所以必须给 Agent 接一个“商机历史查询”工具拿最近几次互动记录来支撑建议。4.2 客服场景从工单分类到跨系统状态同步客服场景我一直认为是 D365 里最适合做 Agent 的领域因为工单处理链路长、判断规则多、人工重复劳动严重。第一版可以先做自动化分类Agent 读取客户提交的描述判断问题类型、紧急程度、影响范围自动创建工单并分派给对应队列。再往前走一步可以让 Agent 做跨系统状态同步。比如某产品发生批量故障时客服收到大量相似投诉Agent 自动发现高频关键词创建一条“故障事件”记录并批量把相关工单关联到该事件下同时更新工单状态为“转内部处理”。这个过程如果没有 Agent人工要一条条看、一条条改而且容易漏。要注意的是批量操作必须先做相似度阈值判断。模型说“这几张工单很像”是不够的你需要给出量化标准比如相似度超过 0.85 才允许批量关联。宁可少关联几条也不要因为模型过于激进把不相关的工单搅在一起。4.3 供应链场景从库存预警到采购建议单生成供应链场景涉及的数据量更大而且一旦出错影响直接体现在实物上。我的建议是先做“建议生成”再做“自动下单”。Agent 发现某 SKU 可用库存低于安全线后先查询近 90 天平均日耗量、当前在途订单、供应商最近报价然后生成一份采购建议单建议采购数量、建议供应商、预计到货时间。这个采购建议单不自动提交审批而是推给采购负责人确认。负责人可以一键批准批准后由 Agent 继续创建采购订单。为什么这里不能全自动因为采购涉及资金和时间承诺而且供应商报价可能有模型不知道的线下约定。让 Agent 把 90% 的信息整理工作做掉把最后一个确认动作留给人反而是效率和安全的最佳平衡。场景查询类工具动作类工具建议审批点销售跟进商机查询、历史互动查询创建任务、发送提醒创建对外邮件前客服工单工单查询、知识库检索创建工单、批量关联批量更新工单前供应链补货库存查询、供应商报价查询生成采购建议单提交采购订单前5. 别一上来就全自动原型期、半自动期、灰度期的三步走5.1 原型期用提示词加人工点击收集真实交互我看到很多团队第一步就急着搭 Agent结果连业务到底要解决什么问题都没定义清楚。更务实的做法是先做一个“提示词助手”版本让业务用户在系统里用提示词提问助手生成操作建议用户手动点击执行但系统要把“用户复制了什么、粘贴到什么页面、点了哪个按钮、最终改了哪个字段”全部记录下来。这个阶段看着很笨但收集的数据极其宝贵。你很快就能看到用户的真实高频动作是什么比如“查看库存”“创建工单”“生成报价单”可能是前三名。这些高频动作就是你后面要做的第一批工具。5.2 半自动期把高频点击变成可调用工具有了真实数据后开始把高频动作封装成工具。每封装一个工具都要和业务负责人确认边界参数是什么、哪些字段必填、操作后会不会触发别的流程。不要直接照抄 API 文档要从业务视角定义工具。比如 D365 里“创建工单”可能只需要调用一个 API但业务上的“创建工单并通知负责人”就涉及建记录、查负责人、发通知三个动作。我倾向于把这类组合动作封装成高级工具因为模型规划时越少做判断出错概率越低。高级工具也能更好地约束权限和审计范围。5.3 灰度期给 Agent 加反馈闭环和急停开关进入灰度期时Agent 已经有能力独立执行一小部分任务了但还不能让它在生产环境里放飞。需要做两件事反馈闭环和急停开关。反馈闭环是指每次 Agent 执行后业务人员可以点“正确”或“错误”错误时填写真实原因。这些反馈会回流成下一阶段优化工具的输入。急停开关则是一个总闸一旦某类任务连续 N 次失败或触发指定错误码系统自动停止该类型任务的自动执行只发通知不再动手。D365 里可以把开关做成一个布尔字段Agent 每次执行前先检查该字段而不是去修改工作流配置。这样运维人员不需要碰代码直接在系统里改一条记录就能实现规则变更。5.4 灰度指标成功率、人工改动率和回滚率灰度期不能用“看起来挺准”来评估要有量化的指标。我每批次灰度至少看四组数据自动执行成功率、执行后被人工修改率、需要升级到人工的比例、平均单次任务耗时。其中“执行后被人工修改率”这个指标很多人会忽略但它其实最能反映 Agent 输出与业务真实预期之间的差距。举个例子如果 Agent 生成的采购建议单里采购数量字段有 60% 会被负责人修改那就说明数量计算逻辑有问题需要调整算法或补上下文如果只有 10% 被修改就可以尝试扩大自动执行范围。这个逻辑和传统的报表看板是不一样的因为这里看的不是业务结果而是人机协作质量。6. 权限、重试和责任边界这三块最容易翻车6.1 权限最小化Agent 不是管理员让 Agent 用服务账号一跑到底是我见过最危险的姿势。D365 的权限模型非常细Agent 一旦拥有太高的权限一次规划失误就可能批量改错记录。正确做法是给 Agent 配置一个专用用户或专用安全角色只授给它工具层涉及的必要权限。每个工具调用时最好模拟实际业务用户的身份。也就是说Agent 代表“销售负责人小王”执行任务时应该用小王的安全角色去操作而不是用统一的管理员账号。这样 D365 原有的字段级权限、记录级权限、团队权限都能自然沿用审计日志里也能明确看到“谁是实际责任人”。6.2 重试与幂等自动执行最怕“做一半”前面已经提过幂等键这里再展开一个真实教训。某次业务方反馈Agent 把一张客户投诉工单创建了三次。排查后发现第一次调用实际成功了但返回超时执行引擎判定失败后触发重试于是又建了两条。人碰到超时会去页面确认一下再决定要不要重试Agent 不会。解决方案是在创建工具里增加查重逻辑创建前先按“客户 标题 摘要哈希”查是否存在未关闭的工单存在就直接返回已有记录。所有会新增记录的工具都要实现“先查后建”这是 Agent 自动执行安全的底线。6.3 审计与责任边界让每个动作都能说清楚自动执行引入后业务人员会关心一个问题这个 AI 干的活出了问题算谁的这个问题不能靠口头回答要靠审计机制回答。我在 D365 里会给每个 Agent 动作写一张审计日志表字段包括 trace_id、触发者、执行用户、工具名称、入参摘要、出参摘要、执行时间、审批人、审批时间、最终状态。这张表的价值在出现争议时才会体现出来。比如采购团队质疑某张采购单的到货日期为什么写错了审计日志能还原整个链路是 Agent 在查询供应商报价时读错了字段还是人工审批时改了参数。没有这套记录Agent 落地稍有波折就会被全盘否定。一个额外的建议是把审批动作也做成 D365 内的记录。不要让审批只发生在聊天窗口里那样审计日志不完整。让 Agent 将待审批动作写入审批实体负责人批准后回写审批结果整个过程既有痕迹也方便后续追溯。最后说一个我最想提醒的事。Agentic AI 在 D365 里的落地难题从来不是选哪个大模型、提示词怎么写而是流程拆解和权限设计。我做的第一个原型效果最好、也最快被业务认可的反而是“自动给客户投诉分类”这件小事那些一上来就想包办整条供应链的项目反而都在评审阶段就被否了。如果你正准备在 D365 里试第一个 Agent建议挑一条问题清晰、反馈可量化、权限干净的流程先跑起来把成功率和人工改动率这两个数测出来再决定要不要往深了做。 
长河君 · 2026/10/22 21:54:53 · 阅读 1.2k D365 Agentic AI落地：从提示词到自动执行的完整路径
干过 D365 落地的人应该都有同感前两年大家还在比谁的提示词写得更花哨现在风向已经变了。提示词写得再漂亮最多也就是生成一段看起来很专业的文案但客户投诉还是没有分派商机跟进还是没人做库存缺料还是没人通知。Agentic AI 在 D365 里的价值不是让对话更聪明而是让模型把提示词理解成一套可执行的行动计划然后真正调用 API、操作业务记录、触发流程把一件事从头做到尾。这篇文章想聊的就是这条从提示词到自动执行的落地路径适合正在做 D365 实施、售前架构或者准备在项目里引入 AI Agent 的团队参考。1. Agentic AI 和传统提示词的分水岭从“生成建议”到“产生结果”1.1 提示词的局限内容产出不等于业务闭环先给一个很常见的画面。某分销企业的客服主管每天让智能助手帮忙汇总客户投诉助手确实能输出一段总结问题分类、涉及产品、建议处理人。但接下来呢工单没有生成负责的销售没有收到通知问题记录没有写入系统。所有“建议”都停留在页面上最后还是有人手动复制粘贴手动建记录手动发消息。这不是提示词质量的问题而是交互模式的问题。传统提示词模式里模型是“顾问”人是“执行者”模型负责生成文本人负责把文本变成业务动作。Agentic AI 反过来模型是“执行者”人是“监督者”模型根据目标自己规划动作、调用工具、检查结果人只在关键节点确认。两者差别可以用一张表说清楚。对比项传统提示词模式Agentic AI 模式输出物文本、建议、摘要系统内可见的业务结果业务流程人来执行AI 辅助AI 执行人审批和监督核心能力语言理解和生成工具调用、任务规划、错误恢复失败处理重新生成提示词补偿操作、升级人工成功标准文本质量高业务数据正确、流程闭环1.2 Agentic 的三个判据我在项目里判断一套系统算不算 Agentic就看三个东西有没有明确目标有没有可用工具有没有反馈闭环。没有目标提示词就只能做单轮问答没有工具模型再聪明也改不了 D365 里的记录没有反馈闭环一次失败了就卡死根本谈不上“自动执行”。D365 恰好三个条件都具备。D365 本身业务对象丰富商机、订单、工单、库存、报价单都是现成的实体Web API、插件、自定义操作提供了大量工具入口审计日志、业务规则、状态流转又能给 Agent 提供执行反馈。可以说D365 是我见过最适合做 Agentic 落地的业务系统之一关键是你能不能把这套逻辑想清楚。1.3 为什么说 D365 是天然的 Agent 试验场很多系统也号称能做 Agent但落地时发现模型“有手难伸”。D365 的优势在于它的业务对象是被完整建模过的字段有类型记录有状态机权限有安全角色操作有插件事件。也就是说Agent 做每一步动作时系统知道这个动作是否合法、是否越权、是否影响下游流程。这种约束对 Agentic AI 不是坏事反而是保证可靠性的基础。2. 在 D365 里设计 Agent先搞清这四个运行要素2.1 指令层把业务流程写成 Agent 能执行的说明书很多人以为 Agent 的系统提示词就是把原来的业务提示词加几个“你可以调用工具”的字眼这是我在复盘时最容易踩的坑。Agent 的指令层应该像一份给新员工看的 SOP而不是一段营销文案。一份能落地的 Agent 指令至少包含五个部分角色和目标可用工具清单业务流程步骤边界条件与拒绝项异常处理方式。我这里给一个简化的模板。你是一个运行在 D365 环境中的业务执行代理。 当前业务目标处理销售团队提交的“商机跟进遗漏”任务。 可用工具 - query_opportunity查询商机基本信息与最近跟进记录 - create_task在 D365 中创建跟进任务 - send_email通过集成的邮件通道发送通知 - update_opportunity_status更新商机状态 执行规则 1. 先查询商机确认最近跟进时间是否超过 3 天 2. 超过 3 天则创建跟进任务负责人取商机所有者 3. 每一步动作前将动作、参数和预期结果写入执行日志 4. 如果查询结果为空或字段缺失停止执行并请求人工确认。这个模板看着简单但关键在于最后两条。让 Agent 把每一步动作写进执行日志是为了事后可以审计让 Agent 在数据不完整时停下来是为了防止它拿着空数据继续胡编乱造。2.2 工具层从 Web API 到插件的能力边界工具层是 Agentic 落地里工作量最大的一块。理论上D365 能暴露成工具的能力非常多实体的增删改查、执行工作流、调用自定义操作、查询视图数据、发送邮件与通知。但实际落地时不能把这些接口一股脑丢给模型。我的做法是把 D365 能力分成三类。第一类是查询类工具比如按条件检索商机、读取库存数量这类工具风险低可以让 Agent 自由调用第二类是创建类工具比如建工单、建任务、生成报价单这类工具会影响数据最好设置人工确认点第三类是状态变更类工具比如关闭订单、取消合同这类工具不可逆或影响面大默认不开放除非单独授权。每次工具调用D365 都会产生插件触发、字段更新、关联记录变化。所以在设计工具层时我建议每个工具都要定义清楚入参校验规则、预期业务影响、可能触发的插件、失败时的补偿动作。工具不是越粗越好也不是越细越好而是要和业务负责人的风险偏好匹配。2.3 上下文层会话记忆、业务数据和规则的叠加Agent 在 D365 里执行任务光有“当前对话”是不够的。比如用户说“帮我处理这张订单”Agent 必须知道“这张订单”指的是哪一条记录、这个客户有什么信用额度、这个产品有没有库存。这些上下文不会自己跑进模型里需要你主动装配。在实践中我通常把上下文拆成三层。第一层是会话上下文记录用户本次交互的目的和历史动作第二层是实体上下文通过查询获取订单、商机、客户等记录的关键字段第三层是规则上下文比如信用审批阈值、库存安全线、节假日日历等业务约束。这里有个容易被忽略的点上下文不是越多越好。把整张订单的全部字段塞给模型既浪费 token又容易让模型忽略关键字段。我的经验是只给模型喂它“做决定”必需的信息其余字段在工具调用时按需再取。2.4 执行与回滚自动操作最怕“做一半”自动执行的底色是可靠性和可恢复性。D365 的插件机制里一次操作可能在创建主记录后触发关联插件如果后面某一步失败前面的已生效改动要不要回退这类问题在人工操作时很好处理人自己知道刚才点了什么但在 Agent 自动执行时如果没设计好幂等和补偿就会留下一堆半成品数据。一个典型的例子是创建“销售订单订单明细”两步操作。如果订单头建好了明细写入时失败Agent 重试第二次就可能产生重复订单头。解决办法是让创建工具支持幂等键用业务编号或 GUID 作为唯一标识创建前先按标识查一遍存在则不重复创建。这个思路和集成对接里防重是一致的只不过现在是 Agent 在替你做这个决策。3. 从提示词到自动执行的架构我反复验证的三段式流水线3.1 第一段意图拆解与任务规划Agentic 流程的第一步是让模型把用户的一句话拆成结构化任务列表。这一段的核心不是执行而是“想清楚要干什么”。比如用户输入“客户 A 的商机快超期了帮我跟进一下”模型不能直接去发邮件而是要规划出查询客户 A 的商机、核对最近跟进日期、判断是否超期、决定是否创建任务或发提醒。实现上这一段建议让模型的输出是严格 JSON 格式的动作序列而不是自然语言。我常用的一种规划结果如下。{ intent: 跟进超期商机, confidence: 0.82, required_approval: false, plan: [ {tool: query_opportunity, args: {account_name: 客户A, status: 活跃}}, {tool: check_last_follow_up, args: {}}, {tool: create_task, args: {task_type: 跟进, owner_auto: true}} ] }这里让模型输出required_approval和confidence字段非常重要。当模型对意图判断不自信或者动作涉及不可逆操作时系统可以自动进入人工确认分支。这个设计比让模型自己“感觉有问题就说一声”可靠得多因为它是结构化的、可被代码控制的。3.2 第二段工具调用与执行验证规划只是纸面计划真正执行时要解决两个问题参数怎么来结果怎么验。很多初版 Agent 失败在参数阶段——模型规划时要查“客户 A”但它只知道“客户 A”这个名字不知道 D365 里这条记录的 GUID。因此执行引擎需要在调用前做参数补全把自然语言名称映射到系统内的唯一标识。验证也不可少。每调用完一个工具Agent 要判断结果是否符合预期。比如调用query_opportunity后返回的商机数量是 0那说明这个客户可能没有活跃商机后续的create_task就不应该执行了。我一般要求执行引擎维护一个小的状态机每个工具定义“成功条件”和“失败分支”而不是让模型自己临场发挥。3.3 第三段结果回写与人工兜底自动执行的最后一段不是“完成”而是“结果可被确认”。Agent 完成后应该在 D365 里留下可查的证据创建了什么记录、改了哪些字段、调用了哪些工具、整个过程的 trace_id 是什么。这些信息既给审计用也给业务用户铺一条“反悔”的路。人工兜底有两种实现。一种是在动作执行前设置审批点Agent 把待执行动作推给业务负责人负责人确认后才继续另一种是在执行后设置观察窗Agent 先执行低风险动作但高风险动作比如发送对外邮件、修改价格要等待人工批准。我建议从第二种开始因为它的自动化程度更高也更贴近 Agentic 的“自动执行”目标。3.4 一个最小可运行的 Agent 执行循环把三段连起来本质是一个循环。我写过一个很粗糙但足够说明问题的伪代码思路是有未完成任务就规划下一步需要批准就中断执行失败就回滚或升级。while pending_tasks: next_step plan(goal, context) if next_step.requires_approval and not approved: request_confirmation(next_step) break result invoke_tool(next_step.tool, next_step.args) if validate_result(result): append_to_audit_log(next_step, result) update_context(result) else: compensate(next_step) escalate_to_human(trace_id) break这个循环看起来简单但它把“想”“做”“查”“补”四件事都覆盖了。实际生产环境里你还要加超时控制、并发限制、token 预算、工具调用次数上限等细节但先把这个循环跑通比一开始追求复杂架构更有价值。4. 三个典型场景怎么落地销售、客服、供应链的 Agent 打法4.1 销售场景商机超期提醒到自动创建跟进任务销售场景最常见的痛点是系统里有大量商机停在某个阶段没人管。传统做法是用报表筛出超期商机然后让销售自己去看Agentic 的做法是让 Agent 把“发现问题”和“解决问题”连起来。我在一个项目里跑过的流程是这样每天早上Agent 查询所有最近跟进日期超过 3 天且阶段未变化的商机针对每条商机生成一句话摘要说明商机金额、已停留天数、建议下一步动作然后自动为商机负责人创建一条跟进任务并把摘要写入任务备注最后Agent 会给销售经理发一个汇总通知列出当天创建的跟进任务清单。这里很容易出问题的是“建议下一步动作”这一步。模型如果没有商机历史记录做上下文就会写出一堆“加强与客户沟通”之类的废话。所以必须给 Agent 接一个“商机历史查询”工具拿最近几次互动记录来支撑建议。4.2 客服场景从工单分类到跨系统状态同步客服场景我一直认为是 D365 里最适合做 Agent 的领域因为工单处理链路长、判断规则多、人工重复劳动严重。第一版可以先做自动化分类Agent 读取客户提交的描述判断问题类型、紧急程度、影响范围自动创建工单并分派给对应队列。再往前走一步可以让 Agent 做跨系统状态同步。比如某产品发生批量故障时客服收到大量相似投诉Agent 自动发现高频关键词创建一条“故障事件”记录并批量把相关工单关联到该事件下同时更新工单状态为“转内部处理”。这个过程如果没有 Agent人工要一条条看、一条条改而且容易漏。要注意的是批量操作必须先做相似度阈值判断。模型说“这几张工单很像”是不够的你需要给出量化标准比如相似度超过 0.85 才允许批量关联。宁可少关联几条也不要因为模型过于激进把不相关的工单搅在一起。4.3 供应链场景从库存预警到采购建议单生成供应链场景涉及的数据量更大而且一旦出错影响直接体现在实物上。我的建议是先做“建议生成”再做“自动下单”。Agent 发现某 SKU 可用库存低于安全线后先查询近 90 天平均日耗量、当前在途订单、供应商最近报价然后生成一份采购建议单建议采购数量、建议供应商、预计到货时间。这个采购建议单不自动提交审批而是推给采购负责人确认。负责人可以一键批准批准后由 Agent 继续创建采购订单。为什么这里不能全自动因为采购涉及资金和时间承诺而且供应商报价可能有模型不知道的线下约定。让 Agent 把 90% 的信息整理工作做掉把最后一个确认动作留给人反而是效率和安全的最佳平衡。场景查询类工具动作类工具建议审批点销售跟进商机查询、历史互动查询创建任务、发送提醒创建对外邮件前客服工单工单查询、知识库检索创建工单、批量关联批量更新工单前供应链补货库存查询、供应商报价查询生成采购建议单提交采购订单前5. 别一上来就全自动原型期、半自动期、灰度期的三步走5.1 原型期用提示词加人工点击收集真实交互我看到很多团队第一步就急着搭 Agent结果连业务到底要解决什么问题都没定义清楚。更务实的做法是先做一个“提示词助手”版本让业务用户在系统里用提示词提问助手生成操作建议用户手动点击执行但系统要把“用户复制了什么、粘贴到什么页面、点了哪个按钮、最终改了哪个字段”全部记录下来。这个阶段看着很笨但收集的数据极其宝贵。你很快就能看到用户的真实高频动作是什么比如“查看库存”“创建工单”“生成报价单”可能是前三名。这些高频动作就是你后面要做的第一批工具。5.2 半自动期把高频点击变成可调用工具有了真实数据后开始把高频动作封装成工具。每封装一个工具都要和业务负责人确认边界参数是什么、哪些字段必填、操作后会不会触发别的流程。不要直接照抄 API 文档要从业务视角定义工具。比如 D365 里“创建工单”可能只需要调用一个 API但业务上的“创建工单并通知负责人”就涉及建记录、查负责人、发通知三个动作。我倾向于把这类组合动作封装成高级工具因为模型规划时越少做判断出错概率越低。高级工具也能更好地约束权限和审计范围。5.3 灰度期给 Agent 加反馈闭环和急停开关进入灰度期时Agent 已经有能力独立执行一小部分任务了但还不能让它在生产环境里放飞。需要做两件事反馈闭环和急停开关。反馈闭环是指每次 Agent 执行后业务人员可以点“正确”或“错误”错误时填写真实原因。这些反馈会回流成下一阶段优化工具的输入。急停开关则是一个总闸一旦某类任务连续 N 次失败或触发指定错误码系统自动停止该类型任务的自动执行只发通知不再动手。D365 里可以把开关做成一个布尔字段Agent 每次执行前先检查该字段而不是去修改工作流配置。这样运维人员不需要碰代码直接在系统里改一条记录就能实现规则变更。5.4 灰度指标成功率、人工改动率和回滚率灰度期不能用“看起来挺准”来评估要有量化的指标。我每批次灰度至少看四组数据自动执行成功率、执行后被人工修改率、需要升级到人工的比例、平均单次任务耗时。其中“执行后被人工修改率”这个指标很多人会忽略但它其实最能反映 Agent 输出与业务真实预期之间的差距。举个例子如果 Agent 生成的采购建议单里采购数量字段有 60% 会被负责人修改那就说明数量计算逻辑有问题需要调整算法或补上下文如果只有 10% 被修改就可以尝试扩大自动执行范围。这个逻辑和传统的报表看板是不一样的因为这里看的不是业务结果而是人机协作质量。6. 权限、重试和责任边界这三块最容易翻车6.1 权限最小化Agent 不是管理员让 Agent 用服务账号一跑到底是我见过最危险的姿势。D365 的权限模型非常细Agent 一旦拥有太高的权限一次规划失误就可能批量改错记录。正确做法是给 Agent 配置一个专用用户或专用安全角色只授给它工具层涉及的必要权限。每个工具调用时最好模拟实际业务用户的身份。也就是说Agent 代表“销售负责人小王”执行任务时应该用小王的安全角色去操作而不是用统一的管理员账号。这样 D365 原有的字段级权限、记录级权限、团队权限都能自然沿用审计日志里也能明确看到“谁是实际责任人”。6.2 重试与幂等自动执行最怕“做一半”前面已经提过幂等键这里再展开一个真实教训。某次业务方反馈Agent 把一张客户投诉工单创建了三次。排查后发现第一次调用实际成功了但返回超时执行引擎判定失败后触发重试于是又建了两条。人碰到超时会去页面确认一下再决定要不要重试Agent 不会。解决方案是在创建工具里增加查重逻辑创建前先按“客户 标题 摘要哈希”查是否存在未关闭的工单存在就直接返回已有记录。所有会新增记录的工具都要实现“先查后建”这是 Agent 自动执行安全的底线。6.3 审计与责任边界让每个动作都能说清楚自动执行引入后业务人员会关心一个问题这个 AI 干的活出了问题算谁的这个问题不能靠口头回答要靠审计机制回答。我在 D365 里会给每个 Agent 动作写一张审计日志表字段包括 trace_id、触发者、执行用户、工具名称、入参摘要、出参摘要、执行时间、审批人、审批时间、最终状态。这张表的价值在出现争议时才会体现出来。比如采购团队质疑某张采购单的到货日期为什么写错了审计日志能还原整个链路是 Agent 在查询供应商报价时读错了字段还是人工审批时改了参数。没有这套记录Agent 落地稍有波折就会被全盘否定。一个额外的建议是把审批动作也做成 D365 内的记录。不要让审批只发生在聊天窗口里那样审计日志不完整。让 Agent 将待审批动作写入审批实体负责人批准后回写审批结果整个过程既有痕迹也方便后续追溯。最后说一个我最想提醒的事。Agentic AI 在 D365 里的落地难题从来不是选哪个大模型、提示词怎么写而是流程拆解和权限设计。我做的第一个原型效果最好、也最快被业务认可的反而是“自动给客户投诉分类”这件小事那些一上来就想包办整条供应链的项目反而都在评审阶段就被否了。如果你正准备在 D365 里试第一个 Agent建议挑一条问题清晰、反馈可量化、权限干净的流程先跑起来把成功率和人工改动率这两个数测出来再决定要不要往深了做。