首页
/ Semantic Kernel项目中处理Azure AI Agent函数结果修改的技术方案

Semantic Kernel项目中处理Azure AI Agent函数结果修改的技术方案

2025-05-08 05:24:17作者:钟日瑜

概述

在微软Semantic Kernel项目中,开发者在使用Azure AI Agent时经常遇到一个典型问题:当插件函数返回特定字符串时,如何确保这些字符串能够原样显示而不被大型语言模型(LLM)修改。本文将深入探讨这一技术挑战及其解决方案。

问题背景

Azure AI Agent作为Semantic Kernel的重要组成部分,提供了自动函数调用(auto function invocation)功能。然而,在某些业务场景下,开发者需要确保函数返回的结果能够100%原样呈现,不受LLM的任何修改。例如:

  • 显示精确的菜单信息
  • 输出系统生成的特定格式数据
  • 展示必须保持原样的技术参数

技术挑战分析

通过Semantic Kernel的自动函数调用过滤器(AutoFunctionInvocationFilter)机制,开发者可以拦截函数调用过程。然而,对于AzureAIAgent和OpenAIAssistantAgent这类服务端代理,存在以下技术难点:

  1. 操作完整性要求:当处理"requires action"事件(初始化的工具调用)并返回工具调用结果后,模型仍需提供最终的自然语言回答,无法简单终止操作。

  2. 运行状态管理:如果尝试提前终止操作,随后再向模型发送输入,会导致错误,因为模型无法处理处于运行中的输入。

  3. 消息顺序维护:需要保持消息的正确顺序,因为工具调用必须对应工具结果。

解决方案实现

基础方案:使用自动函数调用过滤器

开发者可以通过注册自动函数调用过滤器来干预函数调用过程:

@kernel.filter(FilterTypes.AUTO_FUNCTION_INVOCATION)
async def auto_function_invocation_filter(context: AutoFunctionInvocationContext, next):
    print(f"Function: {context.function.name}")
    await next(context)
    result = context.function_result
    if "menu" in context.function.plugin_name.lower():
        context.function_result = FunctionResult(
            function=result.function,
            value="We are sold out, sorry!",
        )
        context.terminate = True

实际应用中的限制

虽然上述方案可以修改函数结果,但存在以下限制:

  1. 无法完全避免LLM对结果的"自然语言加工"
  2. 服务端代理需要完成完整的调用流程
  3. 消息顺序必须严格保持

替代方案:上下文对象模式

针对这些限制,开发者可以采用以下替代方案:

  1. 在KernelArguments中传递上下文对象
  2. 被调用函数修改上下文对象的属性值
  3. 运行完成后,直接从上下文对象获取值并添加到线程
# 伪代码示例
context = KernelArguments()
context["raw_output"] = None

# 函数内部
def get_specials():
    context["raw_output"] = "原始字符串"
    
# 运行后处理
thread.add_message(AuthorRole.ASSISTANT, context["raw_output"])

最佳实践建议

  1. 明确需求优先级:如果必须保证原始输出,考虑使用上下文对象模式
  2. 合理使用过滤器:对于允许LLM加工的内容,使用过滤器进行适当干预
  3. 消息处理策略:利用on_intermediate_message回调处理中间步骤内容
  4. 版本兼容性:注意agent.add_chat_message()的弃用,改用agent.invoke直接传递消息

未来发展方向

随着Semantic Kernel的持续演进,预计将提供更灵活的函数结果处理机制,可能包括:

  • 更细粒度的结果修改控制
  • 服务端代理的早期终止支持
  • 更完善的原始结果保留机制

结论

在Semantic Kernel项目中处理Azure AI Agent的函数结果修改需求,需要根据具体场景选择合适的方案。对于严格要求原始输出的场景,上下文对象模式目前是最可靠的解决方案;而对于允许一定加工的内容,自动函数调用过滤器提供了足够的灵活性。开发者应充分理解各种方案的优缺点,根据实际需求做出合理选择。

登录后查看全文
热门项目推荐

项目优选

收起
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
176
261
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
860
511
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
129
182
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
259
300
ShopXO开源商城ShopXO开源商城
🔥🔥🔥ShopXO企业级免费开源商城系统,可视化DIY拖拽装修、包含PC、H5、多端小程序(微信+支付宝+百度+头条&抖音+QQ+快手)、APP、多仓库、多商户、多门店、IM客服、进销存,遵循MIT开源协议发布、基于ThinkPHP8框架研发
JavaScript
93
15
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
332
1.08 K
HarmonyOS-ExamplesHarmonyOS-Examples
本仓将收集和展示仓颉鸿蒙应用示例代码,欢迎大家投稿,在仓颉鸿蒙社区展现你的妙趣设计!
Cangjie
398
371
note-gennote-gen
一款跨平台的 Markdown AI 笔记软件,致力于使用 AI 建立记录和写作的桥梁。
TSX
83
4
CangjieCommunityCangjieCommunity
为仓颉编程语言开发者打造活跃、开放、高质量的社区环境
Markdown
1.07 K
0
kernelkernel
deepin linux kernel
C
22
5