给C工业软件搭建 Agent这篇文章介绍如何给C/Qt写的桌面软件搭建自身的agent让agent直接操控软件干活这不是skill/mcp也不需要软件提供cli尤其适合工业软件加入agent这篇文章基于我维护的一个开源的工作流和数据分析软件项目地址github:data-workbench国内镜像gitee:data-workbenchdata-workbench 是我开源的一个数据分析软件C17 加 Qt 写界面层内嵌 Python 跑 pandas 和 numpy主要给科研实验数据做清洗、分析、绘图内嵌工作流可以执行一些固有数据分析任务软件最开始是为了实现简单的数据分析避免操作pandas、numpy、matplotlib等各种各样花里胡哨的函数。同时呢集成了一个工作流这样重复性的数据分析能变成一个固有的流程。但随着AI的发展这些功能已经可有可无于是我给它补上了 Agent 功能通过内部 Agent 对话直接操作软件自身功能可以查数据、让ai画图、画完的图用户自己可以手动调整可以生成分析报告等等。Agent 分析数据自动出报告的效果。Agent 自动绘图的效果。给这个桌面软件添加Agent的功能我手写的代码很少。真正干活的是 zcode、kimi code、qwen code、deepseek harness 这几个 coding agent我穿插着用模型主力是 glm-5.2中间还体验过 qwen3.8-plus、deepseek-v4-flash前前后后差不多两亿 token 就可以搭建一个相对完备的agent花费也就几百块钱而已后续就是工具的调整和完善。这篇文章主要基于data-workbench这个C项目介绍如何让 AI 替你在你的某个项目中加入agent功能。最后会提供一组提示词通过这组提示词即可让ai基于你的项目搭建出一个agent目前我已经在其它项目测试过无论是java写的还是c#写的项目都可以很轻松地搭建任意软件增加Agent功能我对Agent的理解核心就是行动循环和提示词注入。Agent就是在调模型解析它想调什么工具执行把结果塞回消息列表再调模型直到它认为完成。实际就一个while循环内部一直调模型直至结束。各种Agent框架langgraph也好自己手写也好都是在给这个循环加工程保障。现在能控制大模型的只有文本因此无论skill还是mcp对模型而言最终都是提示词的一种注入。大模型是无状态的实际开发Agent你会发现每次请求都是一个大大的json把所有会话拼接起来让大模型能“知道”之前的对话信息你可以塞入之前的对话你也可以加入其它的东西例如Agents.md的内容一个Agent核心是提供的工具尤其是垂直领域Agent例如工业软件你提供了什么工具就决定了Agent能操作软件的哪些功能。这里会面临一个问题软件的功能非常多的时候尤其是工业软件可能会要暴露非常多的工具这是后续需要解决的问题工具包含两段内容一段是 JSON Schema告诉模型有哪些功能、参数是什么。另一段是执行器模型要调用时程序去执行把结果作为一条消息返回。目前data-workbench提供了 23 个C工具DAAgentTools插件21个 DAPaperAgent插件2个工具的执行是C端执行的且工具全部通过插件注入可以自由扩展——插件化注入机制后面单独一节细讲data-workbench中增加agent的架构和方法data-workbench 是桌面软件C 生态里没有趁手的 agent 框架生态最丰富的是Pythondata-workbench 选用的是Python的langgraph,把Agent的推理循环、上下文管理、重试、子 agent 编排全部跑在一个 Python 子进程里。工具执行全部留在 C 主进程。两边用 stdin/stdout 管道通信一行一条 JSON。Python 子进程C 主进程 Qtstdin 写user_msg / tool_resultstdout 读token / tool_call / message_end界面 / 数据工作区 / 绘图区 / 工具执行DAAgentBridgeQProcess JSON Lines 协议langgraph 推理循环 / 上下文压缩 / 重试langchain-openai → OpenAI 兼容 API 流式这种架构和开发语言无关无论你是c/c、c#、java写的应用都可以简单快速实现唯一劣势是打包时要带个python环境data-workbench本来就内嵌Python跑pandas子进程直接复用这套环境连这个劣势也不存在工具执行留在 C 是因为本身就是要让agent操作软件自身因此工具都是你要改造的软件本身来执行。LLM 那边只拿到工具 schema真正执行时经管道 RPC 回调到主进程直接就是当前软件界面上的真实对象。这是工业软件做 agent 最舒服的一点你的工具层就是你的业务层中间不需要任何胶水。推理放子进程也是更好的隔离。LLM 思考过程不会影响GUI线程就算 Python 子进程崩了主程序还活着桥接层检测到异常退出会自动重启它从磁盘上的会话记录恢复历史重发最后一条用户消息用户最多感觉到思考时间变长而已目前>实际开发agent需要考虑的点实际上让Agent搭建Agent很快就能完成但细节的调教是很花费时间的。给data-workbench嵌入agent功能只用了2天当时用的qwen code/zcodeglm-5.2从web界面、跨进程通信、行动循环到工具封装几轮任务就完成得很好但后续实际调试中会遇到很多细节问题需要逐一调整。重连和容错这点非常关键大模型会有各种可能返回的异常问题例如没钱了例如请求太多受限了这些都是实际工程问题往往第一遍ai给你写的时候是会忽略的问题需要后续测试补充上上下文压缩和管理在Agent功能跑通后上下文的管理很关键其中压缩是一个关键点ai接口是无记忆状态的让用户感觉到有记忆完全取决于你的上下文怎么拼接而上下文的拼接都是由客户端来决定的同时还会涉及到压缩问题什么时候开始压缩怎么压缩都比较有讲究这些最好的思路就是参考当前开源的agent防循环卡死Agent有时会反复调用同一个工具同样的参数一遍一遍安安静静把 token 烧光。这也是工程性问题初次开发agent非常容易忽略插件化注入领域Agent一个好的软件一定是模块化和插件化的你的软件提供的是基础平台领域业务功能是通过插件注入的这样才能满足不同领域业务的需求也能轻松扩展各种功能。Agent功能也不例外data-workbench的agent能力分两层。平台层是C封装的DAAgent模块只做和领域无关的事负责推理桥接、工具执行调度、权限门、会话持久化、子agent编排等工作主要就是处理python进程信息和c端程序通信和调度。为了满足具体业务功能的需求所有的工具和提示词都是可以通过插件注入的。为此data-workbench设计了一个插件接口DAAgentInterfaceDAAgentInterface开了四个注入口注入口注入什么例子registerTool单个工具schema 执行器可注入各种软件操作的工具例如工程加载、数据查询、建图加曲线等registerSystemPrompt一段命名的系统提示词片段可注入各种业务场景特定的提示词选择不同的agent可以以不同的提示词开始工作registerBuiltinAgent一整个领域agent提示词 配套工具可以直接提供一个完整的agent工具到界面中例如./plugins/DAPaperAgent论文撰写助手registerBuiltinSubagent一个子agent定义可以注册一个调研subagent或者注册一个探索subagent插件层平台层 DAAgentregisterTool / registerSystemPromptregisterBuiltinAgent / registerTool / registerSystemPrompt推理桥接 / 工具执行调度 / 权限门 / 会话持久化 / 子agent编排DAAgentTools 插件21个工具 提示词片段DAPaperAgent 插件论文撰写助手agent 2个文献工具data-workbench的具体agent能力目前通过两个插件提供一个是提供工具让agent调用名为DAAgentTools插件源码位于./plugins/DAAgentTools一个名为DAPaperAgent是做的论文写作的agent演示了系统提示词的注入和特有工具的注入源码位于./plugins/DAPaperAgent。后续我会开发更多的插件注入到软件中例如信号处理插件、工作流编排插件等等。这里简单介绍我现在做好的两个插件DAAgentTools插件注入21个工具数据类list_data-列举所有数据、query_data-查询数据、get_column_stats-获取列数据的基础统计信息等5个、绘图类create_chart-创建绘图、add_curve-添加曲线、set_axis-设置坐标轴样式等11个、文件报告类3个、脚本执行类2个外加一段系统提示词教agent怎么在data-workbench里引用图表。DAPaperAgent插件注入的是一个完整agent——“论文撰写助手”设计了六阶段论文写作流程的提示词外加search_literature-文献搜索、verify_doi-文献信息确认两个文献工具确保ai获取的文献是真实文献。插件装进plugins目录平台上就多了一个会写论文的agent主程序仅仅提供框架不做业务。自定义论文写作agent论文写作agent提供了search_literature-文献搜索、verify_doi-文献信息确认两个文献工具,确保文献正确这么做的好处有三个。第一领域业务团队不碰主程序。想给软件加个特殊行业的agent不需要了解主程序的agent如何实现只需要了解如何注册工具和提示词即可插件支持热插拔可以把不需要的工具或者插件剔除。第二工具就在C主进程内执行工具层就是业务层直接操作软件接口没有序列化开销没有RPC胶水这是MCP/skill这类体外方案做不到的程序能暴露多少接口ai就能操作多少内容理论上整个程序所有接口ai都可以操作。第三所有插件注入的工具执行时也统一接受平台权限管理插件开发者也无需管理权限的问题。怎么让 AI 替你把 agent 造出来前面说过这套带权限、带子 agent、带会话管理、可以直接操作软件自身的agent功能我没有手写多少代码用qwen code/zcode/kimi code这些搭配glm-5.2轻松搞定现在有glm-5.3或kimi-k3理论上会做的更好。这里讲讲给到coding ai的提示词及注意的地方这样任何软件按照这套提示词都可以增加agent功能你首先需要了解一个完整的 agent 由哪些能力组成最好去看看开源的agent是怎么做的这里可以看看我另外一篇文章专门拆解了7个开源agent拆了七大开源 Agent 的源码最高分竟然不是 Codex第一次任务并不需要一次全做但得知道每一项的存在和它解决的问题在完成框架搭建后一步一步补充即可能力解决什么问题必要性推理循环调 LLM、解析 tool_calls、执行、回传、继续必要工具系统声明式工具 JSON Schema 注册执行必要通信与隔离推理不阻塞主程序双向流式协议必要对话 UImarkdown 渲染、工具调用折叠、双向桥接必要人机交互 HITLagent 能在对话流里向用户提问回答后继续必要系统提示词分段拼接、运行时注入、防注入转义必要配置与安全LLM 配置、连接测试、apikey凭据加密必要上下文管理token 估算、阈值压缩、摘要重组历史必要循环防卡死最大步数、循环检测、配对兜底必要重试与恢复429、断网、限流下退避重试必要会话管理多会话、持久化、崩溃后恢复按需权限系统每工具允许/询问/拒绝、路径保护按需子 agent 调度派发独立子任务、收窄工具与权限按需skill支持让agent支持自定义skill按需mcp支持让agent支持mcp协议按需记忆让agent自我总结记忆按需agent 是个大工程可以通过下面提示词让一个code agent基于你自身的系统制定一个计划有经验的架构师好好审查该计划进行完善再让ai执行这里建议使用grill me技能让ai先制定完善的方案再执行为 {平台名} 新增 AI Agent 能力让用户在 {使用场景} 通过自然语言对话调用大模型对 {数据} 进行 {分析、可视化、报告生成等能力}。 第一步识别我当前系统的技术架构和现有能力。桌面端还是 Web 端、什么框架、什么构建系统、现有的数据与可视化能力如何据此选择与之匹配的隔离方式、通信方式、渲染方式。下面每条都是平台中立的设计要求只说目标与原因具体机制由你按我当前架构选在计划里说明理由与我的架构冲突先和我确认。 一、推理与宿主隔离。LLM 推理、API 调用、工具编排放在不阻塞主程序的执行单元里桌面端就是子进程或独立线程。不使用时零开销执行单元出问题主程序要能恢复到可用状态。 二、框架与 LLM 接入。选一个原生支持「向用户提问、用户选择后继续推理」的 agent 框架Python 后端 LangGraph 是成熟候选其它栈给出两三个候选和取舍。LLM 走 OpenAI 兼容 API 加流式做 provider 抽象不绑死任何一家 SDK。 三、流式输出。逐 token 到 UIchunk 里的 tool_call 按 index 累积拼接不能逐 chunk 当完整参数。渲染增量追加并做防抖工具调用和结果在对话流里折叠展示。 四、人机交互。提问直接出现在对话流里不弹模态窗用户选择后答案回传继续推理支持多轮提问。 五、工具体系。统一接口例如getToolSpec 返回 JSON Schemaexecute 返回 JSON 结果。注意大数据集返回摘要而非全量失败返回 success false 不抛异常带超时。 六、系统提示词分段拼装平台基础加领域扩展加工具规格自动注入外部注入的内容转义后再拼防 prompt 注入。 七、分层架构。通用能力做平台模块领域能力经注册注入不把领域逻辑写进通用模块。 八、配置与安全。api key 加密存储不写日志不打控制台。文件工具限制在工作目录路径词法规范化防越界拒绝敏感文件。 九、错误处理。每个 tool.call 必须有配对的 tool.result中断、超时、取消都要合成错误结果兜底否则下一轮请求会被 provider 拒绝对话卡死。 十、分阶段交付每阶段可独立验证。先模块骨架再核心循环再对话 UI再生命周期再内置工具再设置页。每阶段实现前先给我看设计确认后再做。总之计划阶段别省计划批准后按阶段推进。实施阶段每一段提示词的套路都一样先让 AI 识别你现在的代码结构和数据流再给设计要求最后带验收标准。上面这段是制定计划用的各实施阶段的提示词照这个套路写即可。雏形出来后再逐步增加相关的功能如上面能力地图提到的上下文管理、循环防卡死、重试与恢复、权限、子 agent等等功能在结合你软件自身增加一些配置类功能。结语data-workbench 完全开源仓库位于 github.com/czyt1988/data-workbench或gitee.com/czyt1988/data-workbench文档在 czyt1988.github.io/data-workbench。支持任意 OpenAI 兼容 API工业软件搭 agent 并不难。工业软件功能非常多按现有思路搭建会面临工具爆炸问题一个大型软件要给agent暴露非常多的工具。data-workbench目前的答案是子agent加工具白名单收窄——主agent只留调度类和通用工具领域工具下沉给子agent模型某一时刻面对的工具数量降下来了。上百个工具对当前大模型来说不至于失控但长对话后是否还能准确调用如此多工具依然有待验证这条路能走多远也需要更多实践检验 给C++工业软件搭建 Agent
给C工业软件搭建 Agent这篇文章介绍如何给C/Qt写的桌面软件搭建自身的agent让agent直接操控软件干活这不是skill/mcp也不需要软件提供cli尤其适合工业软件加入agent这篇文章基于我维护的一个开源的工作流和数据分析软件项目地址github:data-workbench国内镜像gitee:data-workbenchdata-workbench 是我开源的一个数据分析软件C17 加 Qt 写界面层内嵌 Python 跑 pandas 和 numpy主要给科研实验数据做清洗、分析、绘图内嵌工作流可以执行一些固有数据分析任务软件最开始是为了实现简单的数据分析避免操作pandas、numpy、matplotlib等各种各样花里胡哨的函数。同时呢集成了一个工作流这样重复性的数据分析能变成一个固有的流程。但随着AI的发展这些功能已经可有可无于是我给它补上了 Agent 功能通过内部 Agent 对话直接操作软件自身功能可以查数据、让ai画图、画完的图用户自己可以手动调整可以生成分析报告等等。Agent 分析数据自动出报告的效果。Agent 自动绘图的效果。给这个桌面软件添加Agent的功能我手写的代码很少。真正干活的是 zcode、kimi code、qwen code、deepseek harness 这几个 coding agent我穿插着用模型主力是 glm-5.2中间还体验过 qwen3.8-plus、deepseek-v4-flash前前后后差不多两亿 token 就可以搭建一个相对完备的agent花费也就几百块钱而已后续就是工具的调整和完善。这篇文章主要基于data-workbench这个C项目介绍如何让 AI 替你在你的某个项目中加入agent功能。最后会提供一组提示词通过这组提示词即可让ai基于你的项目搭建出一个agent目前我已经在其它项目测试过无论是java写的还是c#写的项目都可以很轻松地搭建任意软件增加Agent功能我对Agent的理解核心就是行动循环和提示词注入。Agent就是在调模型解析它想调什么工具执行把结果塞回消息列表再调模型直到它认为完成。实际就一个while循环内部一直调模型直至结束。各种Agent框架langgraph也好自己手写也好都是在给这个循环加工程保障。现在能控制大模型的只有文本因此无论skill还是mcp对模型而言最终都是提示词的一种注入。大模型是无状态的实际开发Agent你会发现每次请求都是一个大大的json把所有会话拼接起来让大模型能“知道”之前的对话信息你可以塞入之前的对话你也可以加入其它的东西例如Agents.md的内容一个Agent核心是提供的工具尤其是垂直领域Agent例如工业软件你提供了什么工具就决定了Agent能操作软件的哪些功能。这里会面临一个问题软件的功能非常多的时候尤其是工业软件可能会要暴露非常多的工具这是后续需要解决的问题工具包含两段内容一段是 JSON Schema告诉模型有哪些功能、参数是什么。另一段是执行器模型要调用时程序去执行把结果作为一条消息返回。目前data-workbench提供了 23 个C工具DAAgentTools插件21个 DAPaperAgent插件2个工具的执行是C端执行的且工具全部通过插件注入可以自由扩展——插件化注入机制后面单独一节细讲data-workbench中增加agent的架构和方法data-workbench 是桌面软件C 生态里没有趁手的 agent 框架生态最丰富的是Pythondata-workbench 选用的是Python的langgraph,把Agent的推理循环、上下文管理、重试、子 agent 编排全部跑在一个 Python 子进程里。工具执行全部留在 C 主进程。两边用 stdin/stdout 管道通信一行一条 JSON。Python 子进程C 主进程 Qtstdin 写user_msg / tool_resultstdout 读token / tool_call / message_end界面 / 数据工作区 / 绘图区 / 工具执行DAAgentBridgeQProcess JSON Lines 协议langgraph 推理循环 / 上下文压缩 / 重试langchain-openai → OpenAI 兼容 API 流式这种架构和开发语言无关无论你是c/c、c#、java写的应用都可以简单快速实现唯一劣势是打包时要带个python环境data-workbench本来就内嵌Python跑pandas子进程直接复用这套环境连这个劣势也不存在工具执行留在 C 是因为本身就是要让agent操作软件自身因此工具都是你要改造的软件本身来执行。LLM 那边只拿到工具 schema真正执行时经管道 RPC 回调到主进程直接就是当前软件界面上的真实对象。这是工业软件做 agent 最舒服的一点你的工具层就是你的业务层中间不需要任何胶水。推理放子进程也是更好的隔离。LLM 思考过程不会影响GUI线程就算 Python 子进程崩了主程序还活着桥接层检测到异常退出会自动重启它从磁盘上的会话记录恢复历史重发最后一条用户消息用户最多感觉到思考时间变长而已目前>实际开发agent需要考虑的点实际上让Agent搭建Agent很快就能完成但细节的调教是很花费时间的。给data-workbench嵌入agent功能只用了2天当时用的qwen code/zcodeglm-5.2从web界面、跨进程通信、行动循环到工具封装几轮任务就完成得很好但后续实际调试中会遇到很多细节问题需要逐一调整。重连和容错这点非常关键大模型会有各种可能返回的异常问题例如没钱了例如请求太多受限了这些都是实际工程问题往往第一遍ai给你写的时候是会忽略的问题需要后续测试补充上上下文压缩和管理在Agent功能跑通后上下文的管理很关键其中压缩是一个关键点ai接口是无记忆状态的让用户感觉到有记忆完全取决于你的上下文怎么拼接而上下文的拼接都是由客户端来决定的同时还会涉及到压缩问题什么时候开始压缩怎么压缩都比较有讲究这些最好的思路就是参考当前开源的agent防循环卡死Agent有时会反复调用同一个工具同样的参数一遍一遍安安静静把 token 烧光。这也是工程性问题初次开发agent非常容易忽略插件化注入领域Agent一个好的软件一定是模块化和插件化的你的软件提供的是基础平台领域业务功能是通过插件注入的这样才能满足不同领域业务的需求也能轻松扩展各种功能。Agent功能也不例外data-workbench的agent能力分两层。平台层是C封装的DAAgent模块只做和领域无关的事负责推理桥接、工具执行调度、权限门、会话持久化、子agent编排等工作主要就是处理python进程信息和c端程序通信和调度。为了满足具体业务功能的需求所有的工具和提示词都是可以通过插件注入的。为此data-workbench设计了一个插件接口DAAgentInterfaceDAAgentInterface开了四个注入口注入口注入什么例子registerTool单个工具schema 执行器可注入各种软件操作的工具例如工程加载、数据查询、建图加曲线等registerSystemPrompt一段命名的系统提示词片段可注入各种业务场景特定的提示词选择不同的agent可以以不同的提示词开始工作registerBuiltinAgent一整个领域agent提示词 配套工具可以直接提供一个完整的agent工具到界面中例如./plugins/DAPaperAgent论文撰写助手registerBuiltinSubagent一个子agent定义可以注册一个调研subagent或者注册一个探索subagent插件层平台层 DAAgentregisterTool / registerSystemPromptregisterBuiltinAgent / registerTool / registerSystemPrompt推理桥接 / 工具执行调度 / 权限门 / 会话持久化 / 子agent编排DAAgentTools 插件21个工具 提示词片段DAPaperAgent 插件论文撰写助手agent 2个文献工具data-workbench的具体agent能力目前通过两个插件提供一个是提供工具让agent调用名为DAAgentTools插件源码位于./plugins/DAAgentTools一个名为DAPaperAgent是做的论文写作的agent演示了系统提示词的注入和特有工具的注入源码位于./plugins/DAPaperAgent。后续我会开发更多的插件注入到软件中例如信号处理插件、工作流编排插件等等。这里简单介绍我现在做好的两个插件DAAgentTools插件注入21个工具数据类list_data-列举所有数据、query_data-查询数据、get_column_stats-获取列数据的基础统计信息等5个、绘图类create_chart-创建绘图、add_curve-添加曲线、set_axis-设置坐标轴样式等11个、文件报告类3个、脚本执行类2个外加一段系统提示词教agent怎么在data-workbench里引用图表。DAPaperAgent插件注入的是一个完整agent——“论文撰写助手”设计了六阶段论文写作流程的提示词外加search_literature-文献搜索、verify_doi-文献信息确认两个文献工具确保ai获取的文献是真实文献。插件装进plugins目录平台上就多了一个会写论文的agent主程序仅仅提供框架不做业务。自定义论文写作agent论文写作agent提供了search_literature-文献搜索、verify_doi-文献信息确认两个文献工具,确保文献正确这么做的好处有三个。第一领域业务团队不碰主程序。想给软件加个特殊行业的agent不需要了解主程序的agent如何实现只需要了解如何注册工具和提示词即可插件支持热插拔可以把不需要的工具或者插件剔除。第二工具就在C主进程内执行工具层就是业务层直接操作软件接口没有序列化开销没有RPC胶水这是MCP/skill这类体外方案做不到的程序能暴露多少接口ai就能操作多少内容理论上整个程序所有接口ai都可以操作。第三所有插件注入的工具执行时也统一接受平台权限管理插件开发者也无需管理权限的问题。怎么让 AI 替你把 agent 造出来前面说过这套带权限、带子 agent、带会话管理、可以直接操作软件自身的agent功能我没有手写多少代码用qwen code/zcode/kimi code这些搭配glm-5.2轻松搞定现在有glm-5.3或kimi-k3理论上会做的更好。这里讲讲给到coding ai的提示词及注意的地方这样任何软件按照这套提示词都可以增加agent功能你首先需要了解一个完整的 agent 由哪些能力组成最好去看看开源的agent是怎么做的这里可以看看我另外一篇文章专门拆解了7个开源agent拆了七大开源 Agent 的源码最高分竟然不是 Codex第一次任务并不需要一次全做但得知道每一项的存在和它解决的问题在完成框架搭建后一步一步补充即可能力解决什么问题必要性推理循环调 LLM、解析 tool_calls、执行、回传、继续必要工具系统声明式工具 JSON Schema 注册执行必要通信与隔离推理不阻塞主程序双向流式协议必要对话 UImarkdown 渲染、工具调用折叠、双向桥接必要人机交互 HITLagent 能在对话流里向用户提问回答后继续必要系统提示词分段拼接、运行时注入、防注入转义必要配置与安全LLM 配置、连接测试、apikey凭据加密必要上下文管理token 估算、阈值压缩、摘要重组历史必要循环防卡死最大步数、循环检测、配对兜底必要重试与恢复429、断网、限流下退避重试必要会话管理多会话、持久化、崩溃后恢复按需权限系统每工具允许/询问/拒绝、路径保护按需子 agent 调度派发独立子任务、收窄工具与权限按需skill支持让agent支持自定义skill按需mcp支持让agent支持mcp协议按需记忆让agent自我总结记忆按需agent 是个大工程可以通过下面提示词让一个code agent基于你自身的系统制定一个计划有经验的架构师好好审查该计划进行完善再让ai执行这里建议使用grill me技能让ai先制定完善的方案再执行为 {平台名} 新增 AI Agent 能力让用户在 {使用场景} 通过自然语言对话调用大模型对 {数据} 进行 {分析、可视化、报告生成等能力}。 第一步识别我当前系统的技术架构和现有能力。桌面端还是 Web 端、什么框架、什么构建系统、现有的数据与可视化能力如何据此选择与之匹配的隔离方式、通信方式、渲染方式。下面每条都是平台中立的设计要求只说目标与原因具体机制由你按我当前架构选在计划里说明理由与我的架构冲突先和我确认。 一、推理与宿主隔离。LLM 推理、API 调用、工具编排放在不阻塞主程序的执行单元里桌面端就是子进程或独立线程。不使用时零开销执行单元出问题主程序要能恢复到可用状态。 二、框架与 LLM 接入。选一个原生支持「向用户提问、用户选择后继续推理」的 agent 框架Python 后端 LangGraph 是成熟候选其它栈给出两三个候选和取舍。LLM 走 OpenAI 兼容 API 加流式做 provider 抽象不绑死任何一家 SDK。 三、流式输出。逐 token 到 UIchunk 里的 tool_call 按 index 累积拼接不能逐 chunk 当完整参数。渲染增量追加并做防抖工具调用和结果在对话流里折叠展示。 四、人机交互。提问直接出现在对话流里不弹模态窗用户选择后答案回传继续推理支持多轮提问。 五、工具体系。统一接口例如getToolSpec 返回 JSON Schemaexecute 返回 JSON 结果。注意大数据集返回摘要而非全量失败返回 success false 不抛异常带超时。 六、系统提示词分段拼装平台基础加领域扩展加工具规格自动注入外部注入的内容转义后再拼防 prompt 注入。 七、分层架构。通用能力做平台模块领域能力经注册注入不把领域逻辑写进通用模块。 八、配置与安全。api key 加密存储不写日志不打控制台。文件工具限制在工作目录路径词法规范化防越界拒绝敏感文件。 九、错误处理。每个 tool.call 必须有配对的 tool.result中断、超时、取消都要合成错误结果兜底否则下一轮请求会被 provider 拒绝对话卡死。 十、分阶段交付每阶段可独立验证。先模块骨架再核心循环再对话 UI再生命周期再内置工具再设置页。每阶段实现前先给我看设计确认后再做。总之计划阶段别省计划批准后按阶段推进。实施阶段每一段提示词的套路都一样先让 AI 识别你现在的代码结构和数据流再给设计要求最后带验收标准。上面这段是制定计划用的各实施阶段的提示词照这个套路写即可。雏形出来后再逐步增加相关的功能如上面能力地图提到的上下文管理、循环防卡死、重试与恢复、权限、子 agent等等功能在结合你软件自身增加一些配置类功能。结语data-workbench 完全开源仓库位于 github.com/czyt1988/data-workbench或gitee.com/czyt1988/data-workbench文档在 czyt1988.github.io/data-workbench。支持任意 OpenAI 兼容 API工业软件搭 agent 并不难。工业软件功能非常多按现有思路搭建会面临工具爆炸问题一个大型软件要给agent暴露非常多的工具。data-workbench目前的答案是子agent加工具白名单收窄——主agent只留调度类和通用工具领域工具下沉给子agent模型某一时刻面对的工具数量降下来了。上百个工具对当前大模型来说不至于失控但长对话后是否还能准确调用如此多工具依然有待验证这条路能走多远也需要更多实践检验