1. 从月均200亿token说起这个项目到底在解决什么问题先把数字摆出来月均200亿token。按一个月30天算日均大约6.7亿token再摊到24小时差不多每秒要处理7700个token的吞吐。这个量级放在个人项目里是相当夸张的它意味着这套东西不是玩具demo而是真的有人在天天用、高频用、长时间挂着用。我第一眼看到这个标题时的反应是一个桌面应用凭什么能跑到这个量级它到底把什么东西做对了答案藏在三个词里AI Agent、桌面应用、全栈。这三个词单拎出来都不新鲜但组合在一起并且做到产品级、开源、80天单人全栈打磨就非常值得拆一拆了。先说清楚这个项目是什么。它是一个跑在本地桌面环境标题里明确提到macOS上的AI Agent应用不是网页版不是浏览器插件而是一个独立的、有完整交互界面的桌面客户端。它能做的事情本质上是把大模型的推理能力、工具调用能力、本地文件系统访问能力、以及多轮任务编排能力打包进一个你每天都会打开的窗口里。你可以把它理解成一个住在你电脑里的智能助手但它比传统助手更主动、更能干活、更能记住上下文。它解决的核心痛点有三个。第一网页版AI工具的状态是易失的。你关掉标签页上下文就散了历史记录要找半天文件要反复上传。桌面应用天然拥有持久化的本地存储和文件系统权限这是网页端给不了的。第二Agent类任务需要长时间运行。一个复杂的多步任务可能要跑几分钟甚至几十分钟网页端一旦断网或者切走就前功尽弃桌面端可以稳定挂着。第三隐私与数据主权。很多人的工作文件、代码、笔记是不愿意往云端传的本地桌面应用配合本地或可控的模型服务能把数据留在自己机器上。适合谁来参考这个项目我认为有三类人。第一类是想从0到1搭建AI Agent的开发者尤其是做全栈的这个项目把前端界面、后端逻辑、模型接入、工具编排、打包分发整条链路都跑通了是极好的学习样本。第二类是想找AI Agent练手小项目的人与其自己从零摸索不如先研究一个已经跑到产品级的开源实现看它怎么处理边界情况。第三类是关注桌面端应用开发的人特别是macOS平台这个项目在窗口管理、系统集成、性能优化上有不少可借鉴的细节。我接下来会从整体设计思路、核心技术点拆解、实操落地过程、以及踩坑排查四个维度把这个项目掰开揉碎讲清楚。不管你是刚入门的小白还是已经做过几个Agent项目的老手应该都能从中捞到点东西。2. 整体设计与思路拆解为什么是桌面端为什么是全栈2.1 桌面端 vs 网页端一次关键的架构取舍很多人做AI Agent的第一反应是做个网页版因为部署简单、跨平台、迭代快。但这个项目偏偏选了桌面端这个决定背后是有硬逻辑的。最直接的原因是文件系统访问。Agent要真正干活绕不开读写本地文件。网页端要访问本地文件只能靠用户手动上传下载体验割裂得厉害。而桌面应用可以直接拿到文件系统权限Agent想读哪个目录、想写哪个文件都是一行代码的事。这个差异在简单对话场景里不明显但一旦涉及帮我整理这个文件夹里的文档把这个项目的代码重构一下这类任务差距就是天壤之别。第二个原因是长任务稳定性。Agent执行复杂任务时往往需要多轮模型调用、工具执行、结果回传。这个过程可能持续几分钟到几十分钟。网页端受限于浏览器标签的生命周期、网络波动、内存回收很容易中断。桌面端是一个独立进程只要不主动关闭就能一直跑这对Agent来说是刚需。第三个原因是系统级集成能力。桌面应用可以调用系统通知、剪贴板、全局快捷键、托盘图标、开机自启等能力。这些看起来是小功能但恰恰是产品级和demo级的分水岭。一个能常驻托盘、随时唤起、任务完成弹通知的Agent和一个必须打开浏览器输网址才能用的Agent使用频率完全不是一个量级。当然桌面端也有代价。跨平台打包麻烦、更新机制复杂、安装包体积大、不同系统适配成本高。这个项目选择macOS优先其实是很聪明的策略——先在一个平台上做到极致验证产品形态再考虑扩展。macOS的用户群体对效率工具付费意愿高、对本地应用接受度高是很好的切入点。2.2 全栈打磨意味着什么一条完整的链路标题里全栈两个字不是随便加的。一个产品级AI Agent桌面应用涉及的技术栈横跨好几个层面我把它拆成五层来看。界面层负责对话展示、任务进度、设置面板、历史记录。这一层要考虑流式输出的渲染性能、长列表的虚拟滚动、Markdown和代码块的高亮、多模态内容的展示。做得糙一点能用但要做到产品级细节非常多。应用逻辑层负责会话管理、任务编排、状态机、错误处理。Agent不是简单的问答它有自己的执行循环——思考、调用工具、观察结果、再思考。这一层的核心是把这个大循环管理好包括中断、重试、超时、并发控制。Agent核心层负责提示词组装、工具定义、模型调用、结果解析。这一层是Agent的灵魂决定了它能不能正确理解任务、选对工具、处理异常。工具的设计尤其关键工具描述写得好不好直接决定模型会不会用、用得对不对。模型接入层负责和各家模型服务对接处理流式响应、token计数、重试、限流。这一层要做抽象让上层不关心底层用的是哪家模型方便切换和对比。系统集成层负责文件系统、进程管理、系统通知、自动更新、打包分发。这一层是桌面端特有的也是很多从网页转过来的人最容易翻车的地方。全栈打磨的意思就是这五层你都得自己搞定没有现成的框架帮你全包。这也是为什么80天听起来不长但实际工作量巨大——每一层都有大量琐碎的细节要处理。2.3 开源策略的考量为什么选择开放项目选择开源这个决定值得说道说道。开源对个人项目来说是把双刃剑。好处是能获得社区反馈、积累口碑、吸引贡献者、倒逼代码质量。坏处是要花时间维护issue、review PR、写文档、处理各种环境差异导致的bug。我推测这个项目开源的动机有几个。第一AI Agent这个领域还在早期没有公认的最佳实践开源能让大家一起探索。第二桌面应用的适配问题太多一个人不可能覆盖所有环境社区能帮忙踩坑。第三建立个人品牌一个跑到200亿token的产品级开源项目对开发者来说是最好的简历。从实操角度看开源项目要活得久有几个关键点文档要写清楚怎么跑起来、依赖要尽量少、配置要有默认值、错误信息要友好。这些在后面的实操部分我会展开讲。3. 核心技术点深度拆解Agent是怎么跑起来的3.1 Agent执行循环从一问一答到自主干活普通聊天机器人的逻辑很简单用户输入模型输出结束。Agent完全不是这个逻辑。Agent的核心是一个循环我把它叫做思考-行动-观察循环。具体来说用户给一个任务比如帮我把这个项目里所有console.log清理掉。Agent不会直接输出一段代码就完事它会这样跑第一步理解任务并规划。模型先分析这个任务需要哪些步骤——找到所有含console.log的文件、逐个读取、判断哪些是调试用的、生成修改后的代码、写回文件。第二步选择工具。Agent需要调用文件搜索工具找到目标文件调用文件读取工具看内容调用文件写入工具做修改。每个工具都有明确的输入输出定义。第三步执行并观察。工具执行后返回结果Agent把结果作为新的上下文继续下一轮思考。如果某个文件读取失败它要能意识到并调整策略。第四步判断是否完成。当所有目标文件都处理完Agent输出最终结果循环结束。这个循环看起来简单但工程上有大量细节。比如循环什么时候该停如果模型一直觉得还没完成怎么办这就需要设置最大轮数限制。再比如工具执行失败了是直接报错还是让模型重试通常的做法是把错误信息回传给模型让它自己决定。还有一个关键点是流式输出。Agent的每一步思考都应该实时展示给用户而不是等全部跑完再一次性输出。这对用户体验影响巨大——用户能看到Agent在干什么心里有底也方便中途打断。3.2 工具系统的设计Agent的手和脚Agent再聪明没有工具也只能动嘴。工具系统是Agent能力的边界设计得好不好直接决定Agent能干什么。这个项目的工具系统我推测包含几类核心工具。文件操作类读文件、写文件、列目录、搜索文件。命令执行类跑shell命令、执行脚本。网络类发HTTP请求、抓取网页内容。信息类获取当前时间、系统信息、环境变量。工具定义有几个关键点。第一描述要精准。模型是根据工具描述来决定用不用的描述写得含糊模型就会用错或者不用。比如读取文件这个描述太笼统应该写成读取指定路径的文本文件内容支持UTF-8编码返回文件全文。第二参数要明确。每个参数的类型、是否必填、取值范围都要写清楚最好给示例。第三错误处理要友好。工具执行失败时返回的错误信息要能让模型理解问题所在而不是抛一个原始异常。我特别想强调工具粒度的问题。工具太粗模型不好控制工具太细模型要调用很多次浪费token还容易出错。比如文件操作是提供一个读写改删的全能工具还是拆成四个独立工具我的经验是拆开更好因为每个工具的语义更清晰模型选择起来更准确。还有一个容易被忽略的点是工具的幂等性。读操作天然幂等但写操作不是。如果Agent因为某种原因重试了一次写操作可能会造成重复写入。所以写类工具最好设计成幂等的或者有明确的覆盖/追加语义。3.3 上下文管理200亿token背后的工程挑战月均200亿token这个数字除了说明用户量大还说明上下文管理是个大问题。Agent的上下文会随着循环不断增长——每轮思考、每次工具调用、每个工具返回结果都要塞进上下文。如果不加控制很快就会超出模型的上下文窗口。上下文管理有几个常用策略。滑动窗口是最简单的只保留最近N轮对话老的直接丢掉。但这样会丢失早期的重要信息。摘要压缩是把老对话用模型总结成一段简短摘要保留关键信息。这个策略效果好但成本高因为要多调用一次模型。分层保留是把信息分成不同优先级系统提示、任务目标、关键结果永久保留中间过程可以压缩。这个项目跑到200亿token我猜它在上下文管理上做了不少优化。一个可能的做法是工具结果的截断。工具返回的内容往往很长比如读一个大文件全文塞进上下文很浪费。可以只保留前若干行加后若干行中间用省略号代替并告诉模型内容已截断。另一个做法是按需检索不把所有历史都塞进去而是用向量检索找出相关的历史片段。还有一个实操技巧是token计数要实时。每次调用模型前都要算一下当前上下文有多少token接近上限就触发压缩。这个计数不能靠估算要用对应模型的分词器精确计算否则容易翻车。3.4 模型接入的抽象层不被任何一家绑死产品级应用不能只支持一家模型。用户可能想用这个也可能想用那个还可能想用本地部署的。所以模型接入层必须做抽象。抽象的核心是定义一个统一的接口比如chat(messages, tools, stream)然后各家模型各自实现这个接口。上层逻辑只依赖接口不关心底层是谁。这样切换模型只需要改配置不用改代码。这个抽象层要处理几个差异点。消息格式不同有的模型用role/content有的用别的结构。工具调用格式不同函数调用的字段名、参数结构各家有差异。流式响应格式不同有的按token流有的按事件流。错误码不同限流、超时、内容过滤的返回方式各异。把这些差异都封装在接入层内部对上层暴露统一的接口这是产品级应用的基本功。我见过太多项目把模型调用逻辑散落在各处想换个模型要改十几个文件那就是没做好抽象。3.5 桌面端特有的技术难点从网页转桌面有几个坑是必踩的。打包体积一个Electron应用动辄几百MB用户下载安装都嫌烦。优化方法包括剔除无用依赖、压缩资源、按需加载。启动速度桌面应用用户对启动速度很敏感超过3秒就觉得慢。优化方法包括延迟加载非核心模块、预编译、减少启动时的同步操作。自动更新桌面应用不能像网页那样刷新就更新需要一套更新机制包括检查版本、下载、校验、替换、重启。系统权限访问文件系统、发送通知、注册快捷键在macOS上都需要申请权限处理不好会被系统拦截。macOS还有几个特有的坑。代码签名和公证不签名的应用用户打开会看到安全警告体验很差。签名需要开发者账号公证需要走苹果的流程。Apple Silicon和Intel的兼容M系列芯片和Intel芯片的架构不同打包时要考虑通用二进制或者分别打包。沙盒机制如果上架App Store沙盒会限制很多能力很多Agent需要的功能在沙盒里跑不了所以这类应用通常选择直接分发。4. 实操落地从零到一搭建的完整路径4.1 技术选型桌面框架怎么选桌面应用开发有几条主流路线各有优劣我做个对比。方案优势劣势适合场景Electron生态成熟、Web技术栈、跨平台体积大、内存占用高快速开发、界面复杂Tauri体积小、性能好、Rust后端生态较新、学习成本追求轻量、性能敏感原生开发性能最佳、系统集成好跨平台成本高、开发慢单平台深度优化Flutter Desktop一套代码多端、UI一致桌面生态不成熟已有Flutter积累这个项目标题提到macOS我推测它可能用了Electron或者Tauri。如果是追求快速迭代和丰富界面Electron更合适如果追求轻量和性能Tauri更好。考虑到Agent应用需要频繁和系统交互、处理大量文本流Electron的成熟生态可能更省心但Tauri的体积优势也很诱人。我的建议是如果你是新手先从Electron入手资料多、坑少、社区大。如果你有一定经验且在意性能和体积可以试试Tauri。不要一上来就追求最优解先跑通再说。4.2 项目结构怎么组织代码才不乱一个全栈桌面应用代码组织很关键。我推荐按功能分层而不是按技术分层。所谓按技术分层就是components/、services/、utils/这种项目一大就乱。按功能分层是chat/、agent/、tools/、settings/每个功能模块内部再分自己的组件、逻辑、类型。一个参考结构大概是这样src/ main/ 主进程代码 window/ 窗口管理 ipc/ 进程间通信 system/ 系统集成 renderer/ 渲染进程代码 chat/ 对话界面 agent/ Agent逻辑 tools/ 工具实现 settings/ 设置面板 shared/ 共享类型和工具 types/ 类型定义 utils/ 通用工具主进程和渲染进程的职责要分清。主进程管窗口、系统、文件、进程渲染进程管界面和交互。两者通过IPC通信。Agent的核心逻辑放哪我建议放主进程因为要访问文件系统和执行命令渲染进程权限受限。4.3 核心模块实现Agent引擎怎么写Agent引擎是整个项目的心脏我把它拆成几个关键部分来讲。任务队列Agent任务可能同时来多个需要排队处理。用一个队列管理先进先出同时限制并发数避免资源耗尽。执行循环核心是一个while循环每轮做四件事——组装上下文、调用模型、解析响应、执行工具。循环的退出条件是模型不再请求工具调用或者达到最大轮数。def run_agent(task, max_turns20): messages build_initial_messages(task) for turn in range(max_turns): response call_model(messages, toolsTOOLS) messages.append(response) if not response.tool_calls: return response.content for call in response.tool_calls: result execute_tool(call.name, call.args) messages.append(build_tool_result(call.id, result)) return 达到最大轮数限制任务未完成这段伪代码看起来简单但每一行背后都有讲究。build_initial_messages要包含系统提示、任务描述、可用工具列表。call_model要处理流式、重试、限流。execute_tool要处理超时、异常、权限。build_tool_result要控制结果长度。中断机制用户随时可能想停止Agent。这需要一套中断信号机制让循环在下一轮检查时退出。注意中断要优雅不能直接杀进程要给正在执行的工具一个收尾的机会。状态持久化Agent跑到一半应用崩了怎么办需要把当前状态存下来重启后能恢复。状态包括消息历史、当前轮数、待执行的工具调用等。4.4 界面实现流式输出和任务可视化界面这块最核心的是流式输出的渲染。模型返回是逐token来的界面要实时更新。这里有个性能陷阱如果每个token都触发一次React重渲染长文本会卡成幻灯片。解决办法是用缓冲区攒一小批再更新或者用虚拟DOM之外的方式直接操作文本节点。任务进度可视化也很重要。Agent在跑多步任务时用户需要知道现在到哪一步了。可以做一个步骤列表每完成一步打个勾正在执行的步骤高亮。工具调用可以展示成卡片显示工具名、参数、结果摘要。代码块和Markdown渲染是刚需。Agent输出的内容经常包含代码、列表、表格要正确渲染。代码块要高亮最好带复制按钮。表格要能横向滚动。这些细节做好了体验提升明显。历史记录管理用户会有很多会话需要能搜索、能分类、能删除。会话列表用虚拟滚动避免会话多了卡顿。每个会话存本地数据库不要存JSON文件查询效率差太多。4.5 打包分发让用户能装上开发环境跑通只是第一步让用户能顺利装上才是产品级的门槛。打包配置要处理好几个点。图标要准备多套尺寸macOS需要.icns格式。应用名、版本号、版权信息要填全。要排除开发依赖只打包运行时需要的。要处理原生模块确保在目标平台能加载。代码签名在macOS上是必须的。没有签名的应用用户打开会看到无法验证开发者的警告很多人到这一步就放弃了。签名需要苹果开发者账号流程是生成证书、配置打包工具、签名、公证、装订。公证是把应用提交给苹果检查通过后会得到一个票据装订到应用里用户打开就不会有警告了。自动更新用现成的方案比如electron-updater。配置好更新服务器地址应用启动时检查新版本有就下载下载完提示用户重启。注意更新包要签名否则会被拒绝。首次启动引导用户第一次打开应用要引导他配置模型服务、选择工作目录、了解基本用法。这一步做得好能大幅降低流失率。5. 常见问题与排查技巧实录5.1 Agent不调用工具怎么办这是最常见的问题。Agent该用工具的时候不用直接编一个答案给你。原因通常有几个。工具描述不清楚。模型不知道这个工具是干嘛的自然不用。解决方法是把描述写具体包含使用场景、输入输出示例。比如不要写搜索文件要写在指定目录下按文件名模式搜索文件返回匹配的文件路径列表支持通配符。系统提示没强调。系统提示里要明确告诉模型你有这些工具可用遇到需要实际操作的任务时应该调用工具而不是凭空回答。有些模型比较懒不强调就倾向于直接回答。任务本身不需要工具。有时候是用户的任务确实不需要工具模型直接回答是对的。要区分这两种情况别误判。模型能力不足。有些小模型工具调用能力弱换个大点的模型试试。如果必须用小模型可以在提示词里给更详细的引导。5.2 上下文超限怎么处理Agent跑着跑着就报上下文超限这是高频问题。排查思路是这样。先确认是不是工具结果太长。读一个大文件、跑一个输出很多的命令结果塞进上下文直接爆掉。解决方法是截断工具结果只保留关键部分并明确告诉模型内容已截断如需完整内容请用其他方式获取。再确认是不是历史消息堆积。多轮对话后历史越来越长。解决方法是滑动窗口或者摘要压缩。滑动窗口简单但会丢信息摘要压缩保留信息但要多调用模型。我的经验是混合用——近期消息保留原文早期消息压缩成摘要。还要注意系统提示和工具定义也占token。工具多了光工具定义就几千token。精简工具描述去掉冗余说明能省不少。5.3 流式输出卡顿怎么优化流式输出卡顿用户看到文字一顿一顿的体验很差。原因和优化方法如下。渲染频率过高。每个token都触发重渲染React的diff开销扛不住。优化方法是缓冲比如每50毫秒或者每积累10个token更新一次。用requestAnimationFrame做节流也行。Markdown实时解析开销大。每来一段就重新解析整个Markdown文本长了就卡。优化方法是只解析新增部分或者流式过程中先用纯文本展示结束后再渲染Markdown。状态管理不当。把整个消息列表放在一个state里每次更新都触发全量重渲染。优化方法是拆分state只更新变化的部分用memo避免无关组件重渲染。5.4 工具执行失败怎么让Agent自愈工具执行失败是常态关键是让Agent能自己处理。做法是把错误信息结构化后回传给模型。错误信息要包含三部分错误类型文件不存在、权限不足、超时、错误详情具体是什么错、建议可以怎么调整。比如文件不存在就告诉模型路径X不存在请检查路径是否正确或者先用列目录工具确认。模型收到这个信息后通常会调整策略——换个路径、换个工具、或者告诉用户需要先做什么。如果模型连续几次都失败就要考虑是不是工具本身有问题或者任务超出了Agent的能力范围。一个实用技巧是给工具调用设重试上限。同一个工具用同样的参数连续失败三次就强制中断避免死循环烧token。5.5 常见问题速查表问题现象可能原因排查方向解决方法Agent不调用工具描述不清/提示未强调检查工具定义和系统提示细化描述、强调工具使用上下文超限工具结果长/历史堆积看token计数分布截断结果、压缩历史流式卡顿渲染频繁/解析重看性能面板缓冲更新、延迟解析工具失败不自愈错误信息不友好看回传的错误内容结构化错误、加建议打包后跑不起来原生模块/路径问题看运行日志检查依赖、用绝对路径签名后仍警告未公证/票据未装订看系统安全设置走完公证流程更新失败签名不匹配/网络问题看更新日志检查签名、换更新源内存持续增长监听未清理/缓存无上限看内存曲线清理监听、限制缓存5.6 几个我踩过的坑坑一IPC通信的数据量。主进程和渲染进程之间传大数据会卡尤其是传文件内容。解决方法是传引用不传内容渲染进程需要时再通过IPC按需拉取。坑二macOS的路径问题。开发时用的相对路径打包后工作目录变了全找不到。解决方法是统一用绝对路径基于app.getPath()来拼。坑三模型返回的JSON解析。工具调用的参数是JSON但模型有时会返回带Markdown代码块的JSON直接parse会失败。解决方法是先清洗去掉json标记再parse还要处理parse失败的情况。坑四并发工具调用。模型可能一次返回多个工具调用如果串行执行会很慢。可以并行执行但要注意有些工具不能并行比如写同一个文件。我的做法是默认并行对有副作用的工具加锁。坑五token计数的误差。不同模型的分词器不同用错分词器算出来的token数不准导致要么浪费上下文空间要么超限。解决方法是每个模型配对应的分词器算不准就留足余量。6. 从200亿token反推产品级Agent的运营心得6.1 用户留存的关键让Agent真的有用跑到200亿token说明用户是真的在用不是装了就忘。我分析有几个原因。Agent能解决真实问题。不是那种你好我好的闲聊而是能帮你整理文件、写代码、查资料、做分析。这些是每天都会遇到的需求用一次省一次时间自然就离不开了。使用门槛低。桌面应用双击就开不用配环境、不用记命令。Agent的交互是自然语言不用学新语法。这两点加起来让非技术用户也能上手。反馈及时。Agent每一步都展示在界面上用户知道它在干什么心里有底。任务完成有通知不用一直盯着。6.2 成本控制200亿token要花多少钱200亿token如果全用商业API成本是相当可观的。按常见的定价输入输出混合算每百万token几美元到几十美元不等200亿token就是几万到几十万美元的量级。这个成本个人项目扛不住所以必然做了优化。优化方向有几个。本地模型分流简单任务用本地小模型复杂任务才用云端大模型。缓存复用相同或相似的请求缓存结果避免重复调用。提示词精简去掉冗余的系统提示能省不少输入token。上下文压缩前面讲过的摘要压缩减少每轮携带的历史。还有一个策略是分级模型。Agent的思考用强模型工具结果的解析用弱模型各取所需。这样能在保证效果的前提下大幅降本。6.3 开源项目的可持续性开源项目最大的挑战是可持续。一个人维护热情会消退时间会被挤占。要让项目活得久有几个建议。降低维护成本文档写清楚常见问题做成FAQ让用户自己能解决大部分问题。issue模板要规范让用户提供必要信息减少来回沟通。建立贡献者梯队把一些独立模块开放出来让社区贡献。给贡献者明确的指引和认可培养核心贡献者。控制范围不要什么需求都接聚焦核心场景。功能越多维护成本越高bug也越多。找到正反馈用户的感谢、star的增长、被引用和推荐这些都是坚持下去的动力。适当展示项目的影响力对自己也是一种激励。6.4 后续可以扩展的方向这个项目已经跑通了核心链路后续可以往几个方向扩展。多模态能力支持图片输入输出让Agent能看图、能画图。这在设计、教育、电商场景很有用。多Agent协作一个Agent能力有限多个Agent分工协作能处理更复杂的任务。比如一个负责规划、一个负责执行、一个负责检查。插件生态开放工具接口让第三方开发者贡献工具。工具越丰富Agent能做的事越多。团队协作支持多人共享会话、共享工具配置、共享知识库。从个人工具变成团队工具价值会放大。跨平台从macOS扩展到Windows和Linux覆盖更多用户。跨平台的核心是抽象好系统相关的部分界面和逻辑尽量复用。我个人在实际操作中的体会是做Agent应用最难的不是技术而是找到那个真正有用的场景。技术方案可以学工具可以抄但场景要靠对用户的理解。这个项目能跑到200亿token说明它找准了场景。如果你也在做类似的东西不妨先想清楚你的Agent到底帮谁解决了什么问题这个问题是不是高频、刚需、现有方案解决得不好。想清楚这个技术才有意义。最后再分享一个小技巧做Agent应用时一定要自己天天用。你自己用着别扭的地方用户一定也会别扭。很多优化点不是想出来的是用出来的。我见过太多项目开发者自己都不用做出来的东西自然没人用。