夜雨聆风
tools/list |
tools/call |
下面将共享下开发过程心得，功能部分实现参考多个AI Agent工具实现，界面参考VSCode,VisualStudio.
一、AI 模型其实只负责“思考”
很多人会把 AI 编程助手理解成一个更聪明的代码生成器。
你告诉它：
帮我修复这个程序无法启动的问题。
它看起来能够分析代码、修改文件、执行编译，甚至根据错误继续修复。
但大模型本身并不能直接操作电脑。
它真正能做的事情，是根据当前看到的信息，判断下一步应该做什么。例如：
读取哪个文件； 搜索哪个函数； 修改哪几行代码； 执行什么编译命令； 根据什么错误继续排查。
真正负责读取文件、修改代码和执行命令的，是编程助手背后的工具系统。
因此，一个完整的 AI 编程助手，可以简单理解为：
大模型负责思考，工具负责执行，宿主程序负责管理。
大模型像大脑，文件读取、代码搜索、编辑器和终端像手脚，而任务记录、上下文和检查点则像它的笔记本。
只有这些部分配合起来，AI 才能真正开始“干活”。
二、从聊天框到智能体，中间差了什么？
最早的实现方式非常简单。
用户提出问题，程序把问题和部分代码发送给模型，模型返回一段回答。
这种方式适合解释代码，却很难完成复杂任务。
因为真实的软件项目通常包含成百上千个文件。模型既不知道项目结构，也不知道应该从哪里开始，更无法确认自己的修改是否正确。
后来，我给编程助手增加了文件读取、目录浏览、代码搜索和命令执行能力。
AI 可以先查看项目目录，再搜索相关类和函数，最后读取准确的代码片段。
到这一步，它才开始从“聊天机器人”变成“编程智能体”。
不过，新的问题很快又出现了。
工具越多，模型越容易选错；代码读取越多，请求消耗越大；任务执行时间越长，越容易出现重复搜索和上下文混乱。
于是，开发重点也从“增加功能”，逐渐转向“约束行为”。
三、不是读得越多，理解得越好
在最初的设计中，为了让模型充分了解项目，我会把大量历史对话、文件内容和工具结果一起发送过去。
这样做看起来信息很完整，实际效果却不一定好。
当上下文越来越长时，真正重要的代码很容易被淹没。模型可能记住了大量日志，却忽略了当前真正需要修改的函数。
这让我逐渐意识到：
上下文的价值不在于多，而在于准确。
现在的思路是先提供项目结构，再让模型根据任务逐步获取信息。
例如修复一个按钮无效的问题，并不需要读取整个项目。通常只需要找到：
这些信息能够形成一条完整的证据链。
模型知道自己为什么要修改，也知道修改会影响哪些地方，而不是凭借一个模糊的代码片段进行猜测。
四、修改代码之前，先证明自己看懂了
AI 修改代码最危险的地方，不是它不会写，而是它可能在没有充分理解的情况下直接动手。
因此，我在编程助手中逐步加入了“先读取、再修改”的限制。
模型需要先获得目标文件的准确内容，确认文件版本没有发生变化，然后才能提交修改。
修改前还会保存检查点，记录原始内容。修改完成后，再保存新的版本和校验信息。
如果结果不正确，就可以恢复到修改前的状态。
这套机制并不能保证 AI 永远不犯错，但可以把错误控制在可恢复的范围内。
我的体会是：
智能体真正需要的不是绝对自由，而是可控的行动能力。
能力越强，越需要明确边界。
只读任务不能修改文件；问答任务不能随意执行命令；不同角色只能使用被允许的工具；危险操作必须经过额外检查。
这些限制看起来降低了 AI 的自由度，实际上却提高了它在真实项目中的可用性。
五、为什么还要支持多个任务？
当编程助手只能同时处理一件事时，使用体验非常像早期的单任务系统。
一个任务正在编译，用户就只能等待；想临时查看另一个问题，也容易打断原来的上下文。
因此，我后来开始增加多任务能力。
同一个项目目录下，可以建立多个独立任务。例如：
一个任务负责修复程序启动问题； 一个任务负责优化界面； 一个任务负责分析 Token 消耗； 另一个任务负责研究新的智能体功能。
每个任务拥有自己的对话、执行状态、上下文和工具结果。
这样做的意义不仅是能够切换页面，更重要的是避免不同任务之间相互污染。
不过，多任务并不等于所有操作都可以无限并发。
模型请求可以分别进行，但编译、文件修改和终端命令需要协调。否则两个任务同时修改同一个文件，很容易产生冲突。
因此，多任务系统背后还需要一个任务协调器，决定谁可以执行、谁需要等待，以及任务停止后如何恢复。
用户看到的是几个简单的任务标签，程序内部处理的却是状态隔离、资源竞争和执行顺序。
这也是软件开发中很典型的一件事：
越简单的界面，背后往往需要越复杂的工程。
六、工具不是越多越好
开发过程中，我还踩过一个很明显的坑：给模型提供了太多工具说明。
文件读取、代码搜索、目录遍历、文本替换、补丁修改、命令执行、Git 操作、任务计划……每个工具都有自己的参数和规则。
如果把所有工具的完整说明都发送给模型，不仅会消耗大量 Token，也会增加模型的选择难度。
后来我开始把工具分层。
基础工具保持稳定，专业能力通过技能按需加载。模型只有在遇到相应任务时，才获得对应的说明。
同时，工具参数尽量保持简单、统一和明确。
这让我得到一个很重要的开发心得：
设计 AI 工具，本质上也是在设计一套给 AI 使用的用户界面。
人类面对复杂界面会迷路，模型面对复杂的工具定义同样会迷路。
好的工具不是功能最多，而是让模型容易选对、容易调用，也容易判断执行结果。
七、真正影响体验的，往往不是模型大小
我们很容易把 AI 编程助手的效果归因于模型。
回答不好，就换一个更大的模型；修改失败，就增加更多提示词。
但在实际开发中，我越来越感觉到，模型只是系统中的一个部分。
真正决定体验的，还有很多工程细节：
是否给模型提供了准确的项目环境； 是否能找到真正相关的代码； 是否会重复读取相同文件； 工具执行结果是否能够被模型理解； 修改失败后能否恢复； 用户是否能看到当前执行进度； 一个任务是否会干扰另一个任务； 程序异常退出后，任务能否继续。
模型能力决定了上限，工程系统决定了下限。
一个模型能力很强，但工具混乱、上下文臃肿、执行过程不可控，最终仍然很难使用。
相反，即使模型并不是最强，只要上下文准确、工具清晰、反馈及时，也能完成大量实际工作。
八、我的一点心得
做 AI 编程助手之后，我最大的变化，是不再把 AI 看成一个“什么都懂的程序员”。
它更像一个反应很快、知识很多，但需要明确工作环境和操作规则的新同事。
你不能只告诉它“把这个问题解决掉”，然后期待它自动理解整个项目。
你需要给它合适的工具、准确的资料、清晰的边界，以及能够检查和恢复的工作流程。
这和带新人其实很像。
刚开始时，我们总想把所有资料一次性交给他。后来才发现，真正有效的方法是告诉他当前目标，让他按照任务一步步查找信息，并在关键节点确认结果。
AI 也一样。
未来的编程助手，可能不会只是编辑器旁边的一个聊天窗口。它会逐渐成为项目中的任务执行者：理解需求、查找代码、制定步骤、完成修改、运行验证，并把整个过程清晰地展示出来。
但无论模型多么强大，有一件事应该始终保持不变：
AI 可以替我们执行很多工作，但最终的判断和责任，仍然属于使用它的人。
这也是我在开发 IOTLink AI 编程助手过程中，最深的一点体会。
我们真正要做的，不是让 AI 看起来更聪明，而是让它在真实工作中，更可靠地完成一件事。
