文章目录1. 三个入口共用一个脑子1.1 常规解法听着优雅实则藏坑1.2 我偏反着来直接内联打包1.3 有得必有失拿复用换踏实2. 就盯着DeepSeek调不做万金油2.1 “模型无关”听着万能实则谁都不合身2.2 照着DeepSeek的脾气量身定做2.3 放弃通用性换针对性3. 别信模型的嘴防犯傻要做在根上3.1 模型不仅会瞎编还会装无辜3.2 工程层硬兜底不信自觉信规则3.3 维护成本不低但换得来放心4. 人和模型是两种观众别一份输出糊弄两头4.1 两头都要的结果就是两头都不爽4.2 举个最直观的例子装依赖4.3 分两路输出各取所需5. 两道边界安全和定位的克制5.1 数据安全先给敏感信息打个码5.2 产品定位就做单人本地工具5.3 主动放弃的就是不打算碰的P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/qq_34419312很多人觉得做个编码Agent门槛在“让它跑起来”。调个模型接口把读写文件、跑命令的工具往提示词里一塞半天就能整出个demo。说实话这步早就不值钱了。就跟你买个拼装玩具照着说明书拼完能立住这不叫本事。真正要命的是立住之后的事儿聊着聊着上下文炸了命令跑崩了它硬说成功了读个配置顺手把你密钥给传云上去了死循环起来token烧得比你工资还快。这些坑不是调调提示词就能填上的。这才是Agent和聊天机器人的分水岭跨不跨得过去全看工程上肯不肯下笨功夫。我自己折腾了个DeepSeek驱动的本地编码Agent插件、终端、本地服务三个入口共用一套核心逻辑。今天不说功能清单就聊聊我踩过分水岭时做的几个选择——赚了啥又亏了啥。一个Agent好不好用说白了就是这些取舍堆出来的。1. 三个入口共用一个脑子1.1 常规解法听着优雅实则藏坑最早纠结的就是VS Code插件、终端CLI、HTTP服务这三个入口怎么安排。常规操作肯定是把核心逻辑抽成个独立npm包三个入口各自引用。优雅解耦听着就很符合工程最佳实践。1.2 我偏反着来直接内联打包我没走这条路直接把核心逻辑内联进三个入口的产物里打包的时候一起编进去。为啥因为核心逻辑还在天天改啊。一旦拆成独立包三个入口各自锁版本用不了两天就会出现插件修了bug终端还在犯同一个错用户用着用着就懵了到底哪个壳配哪个版本内联就没这毛病三份产物永远是同一份代码改一处全生效。再加上共享同一个本地数据目录同一个项目的会话你在插件里开的头切终端能接着唠切本地服务也能续上。1.3 有得必有失拿复用换踏实代价也很实在核心逻辑没法被别人当库引用了构建链路也复杂了不少。说白了就是拿可复用性换了三端百分百的一致性。别人都追求优雅解耦我承认这东西还在野蛮生长期干脆强耦合换个踏实。2. 就盯着DeepSeek调不做万金油2.1 “模型无关”听着万能实则谁都不合身很多Agent框架都爱标榜“模型无关”换啥模型都能跑。听着很万能对吧但万能的另一面就是对谁都没那么贴心。就像通用款的衣服谁都能穿但谁穿都不合身。2.2 照着DeepSeek的脾气量身定做我这套治理逻辑全是照着DeepSeek的脾气调的。就说上下文压缩这事儿通用框架按教科书比例算就行。但DeepSeek有自己的特点本地估的token数和真实用量有固定偏差还有隐式前缀缓存命中了能省一大笔。按通用逻辑来要么压缩慢半拍以为还安全其实马上就炸最后靠接口报错兜底要么该吃缓存红利的时候一压缩全给打穿了。我就做了两件事每轮用真实token用量校准本地估算压缩时机看缓存命中率命中率高就晚点压接着吃红利低了再早点压。2.3 放弃通用性换针对性这么干的好处很明显长任务跑得稳token都花在刀刃上。代价也很直白换个模型这套逻辑基本就得重调。说白了就是拿通用性换针对性。对本地工具来说我觉得这笔买卖划算。3. 别信模型的嘴防犯傻要做在根上3.1 模型不仅会瞎编还会装无辜跟模型打交道久了你就会认清一个现实它不仅会瞎编还会选择性失明。命令明明跑报错了它能假装没看见转头告诉你“执行成功”。还会陷进同一个调用里来回横跳token烧得哗哗的它自己完全没知觉。就像你家猫打翻了水杯还一脸无辜看着你仿佛不是它干的。3.2 工程层硬兜底不信自觉信规则我的理念很简单别指望模型自己老实工程层必须兜底。所以工具协议里专门加了个校验结果的字段工具底层自己分析输出硬判成功还是失败。一旦判失败直接在喂给模型的结果里插一句系统判定执行失败别盲目乐观老老实实看报错。再加上死循环熔断、轮数收敛、兜底上限全是一个路子不信嘴信硬规则。3.3 维护成本不低但换得来放心麻烦也是真麻烦。每个工具都得单独写判定逻辑维护成本不低。边界情况也头疼比如一个warning到底算不算失败得反复斟酌。但换回来的是不用人盯着的自动化才敢真的放手让它跑。多数框架的工具就是个执行函数跑完拉倒信不信全看模型自觉。我偏把“防犯错”提到协议层当成每个工具定义时就得想明白的头等事。4. 人和模型是两种观众别一份输出糊弄两头4.1 两头都要的结果就是两头都不爽这点我最想单独唠唠。一个工具跑完输出给谁看既给人看也给模型看。但这俩要的东西根本不是一回事。4.2 举个最直观的例子装依赖跑个npm install终端能刷出两千行下载进度还有进度条动画。用户就爱看这个看着进度条往前走心里踏实跟追剧看更新似的。但模型呢它只想知道一句“装好了45个包”。你把两千行原样喂给它它注意力全被噪音淹了根本抓不住重点。可你只喂一句结论用户又觉得干巴巴的啥过程都看不到没安全感。4.3 分两路输出各取所需我的解法就是分两路一路给人看生动、流式、有动画该有的仪式感都有一路给模型干净、简短、只留结论。两头都伺候舒服了。代价就是输出杂的工具得多写一道分流逻辑那些输出本就干净的简单工具这层就有点多余。但总比一份输出两头不讨好强。5. 两道边界安全和定位的克制5.1 数据安全先给敏感信息打个码先说数据这道边界。DeepSeek是云端模型意味着Agent读的每个文件、跑的每条命令结果都得发出去。那读到.env、读到数据库密码怎么办总不能直接裸奔发出去吧。我的处理是脱敏含密钥的内容发往云端之前按规则换成星号。本地该怎么用怎么用云端只见打码后的内容。说实话这是治标。数据终究出了本机肯定不如纯本地模型彻底脱敏规则也得维护漏了新型密钥、误伤正常内容都是可能的坑。但至少把“用云端大脑干本地活”最扎人的那根刺给拔了。5.2 产品定位就做单人本地工具再说说产品这道边界。我从一开始就定了性这就是个单人本地工具。不做公网部署不做多租户不做SaaS也不背服务端那套沙箱的包袱。HTTP服务也只开在本地127.0.0.1当个程序化入口就行。为啥这么克制单人本地工具“让用户敢放手用”比啥都重要。省下来的复杂度我全投到体验上了审批、脱敏、Undo回退全围着“敢不敢让它放手干”这一个目标做。5.3 主动放弃的就是不打算碰的代价也明摆着天然不支持团队协作安全上限就是单机水平。这是主动选的也是实打实的局限。想拿它搭团队平台的趁早不用看了。折腾完这一套我越来越觉得Agent这东西门槛从来不在“能跑起来”而在“跑起来之后好不好用、敢不敢用”。半天整出个demo不难难的是填上后面那些坑上下文爆炸、睁眼说瞎话、密钥裸奔、死循环烧token。而填这些坑说到底全是在做取舍。拿通用性换针对性拿可复用性换一致性拿开发量换可靠性。每个选择都有代价我只是老老实实接受这些代价换我最想要的那点东西。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/qq_34419312