干过 D365 落地的人应该都有同感：前两年大家还在比谁的提示词写得更花哨，现在风向已经变了。提示词写得再漂亮，最多也就是生成一段看起来很专业的文案；但客户投诉还是没有分派，商机跟进还是没人做，库存缺料还是没人通知。Agentic AI 在 D365 里的价值，不是让对话更聪明，而是让模型把提示词理解成一套可执行的行动计划，然后真正调用 API、操作业务记录、触发流程，把一件事从头做到尾。这篇文章想聊的就是这条从提示词到自动执行的落地路径，适合正在做 D365 实施、售前架构，或者准备在项目里引入 AI Agent 的团队参考。

1. Agentic AI 和传统提示词的分水岭：从“生成建议”到“产生结果”

1.1 提示词的局限：内容产出不等于业务闭环

先给一个很常见的画面。某分销企业的客服主管每天让智能助手帮忙汇总客户投诉，助手确实能输出一段总结：问题分类、涉及产品、建议处理人。但接下来呢？工单没有生成，负责的销售没有收到通知，问题记录没有写入系统。所有“建议”都停留在页面上，最后还是有人手动复制粘贴，手动建记录，手动发消息。

这不是提示词质量的问题，而是交互模式的问题。传统提示词模式里，模型是“顾问”，人是“执行者”；模型负责生成文本，人负责把文本变成业务动作。Agentic 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，建议挑一条问题清晰、反馈可量化、权限干净的流程先跑起来，把成功率和人工改动率这两个数测出来，再决定要不要往深了做。