北京
大多数企业级智能代理的演示，都在最关键的地方作弊。
它们展示一个漂亮的聊天窗口，连上一个玩具API。代理调用函数，拿到干净的JSON响应，所有人点头称是。然后你试着把同样的模式套到真正的SAP系统上——授权、OData过滤器、奇怪的字段名、数据最小化、审计日志，还有那个令人不安的事实："让模型去查询SAP"根本算不上架构。
这篇文章展示的是我会真正开始用的版本。
场景故意设计得很无聊：一个支持或运维人员询问某笔客户订单为什么被冻结。代理应该查找一小片经过批准的SAP数据，总结情况，并建议下一步操作。不直接访问数据库。不让模型生成OData查询。没有那种写着"注意安全"然后听天由命的魔法提示词。
我把系统拆成四个部分：
Azure AI Foundry托管代理并处理对话。代理只获得一个狭窄的工具，比如get_order_status。后端服务负责SAP集成，调用经过批准的OData端点。身份认证、日志记录和策略控制放在提示词之外。
代理被允许提问。工具被允许获取特定的业务对象。SAP层被允许执行那些丑陋但必要的规则。
这种分离很重要。如果模型能随意编造OData查询，它也能编造昂贵的、范围过大的或未经授权的查询。如果后端只暴露一个带有类型化参数的小型函数，爆炸半径就会小得多。
一个最小化的生产级流程看起来是这样：
用户 → Teams/网页应用/Copilot扩展 → Azure AI Foundry代理 → 函数工具：get_order_status(order_id) → 集成API → SAP OData端点/SAP BTP目的地/API管理 → 净化后的JSON返回给代理 → 简短回答+下一步行动。
我喜欢在Foundry和SAP之间放置Azure API管理或一个小型集成API。它给你一个统一的地方来做限流、日志记录、白名单、关联ID和请求验证。以后更换SAP后端时，也不用教代理新把戏。
SAP这边保持无聊。下面是一个故意做得很小的Python客户端，用于SAP OData端点。重要的不是HTTP库。重要的是调用者不能传递任意过滤器。
代码里，OrderStatus数据类明确定义了返回字段：订单ID、客户名称、生命周期状态、交付冻结、信用冻结、净值、货币。SapClient类从环境变量读取配置，get_order_status方法对订单ID做严格校验——必须是数字且不超过12位，否则直接抛出异常。
这里没有动态查询构建。没有字符串拼接。只有固定的端点、固定的字段、固定的返回结构。
这就是企业级代理的真正起点：不是让模型更聪明，而是让它更没机会犯错。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
