在AI技术日新月异的今天，大语言模型已经能够流畅对话、生成代码、撰写文章，但一个关键痛点始终困扰着开发者：AI无法自主操作文件系统。当用户想让AI“读一读你的项目文件”时，往往需要手动复制粘贴代码、整理文件夹结构，每一次交互都像是隔着玻璃端操作。而传统的做法，是借助LangChain等框架来搭建Agent，但这意味着要依赖复杂的生态、学习陡峭的API，甚至为几十行功能引入大量依赖。

如今，一股“手搓Agent”的技术浪潮正在悄然兴起。开发者们开始尝试绕开厚重的框架，用更轻量、更透明的方式，为大模型装上一双能“动手”的“手”，让AI真正拥有感知和操作本地文件的能力。

框架的“包袱”：为什么LangChain并非万灵药？

LangChain无疑是当前最流行的AI应用框架之一，它为Agent、工具调用、记忆管理等提供了一套成熟方案。然而，在实际开发中，不少工程师发现，当需求并不复杂时，引入LangChain反而像“杀鸡用牛刀”。其抽象层过深、调试困难、依赖版本兼容性问题频发，且每个新功能往往需要学习全新的模块。更重要的是，面向企业级应用，我们有时只需要让AI“读一个目录结构”或“搜索一个关键词”，但LangChain会将其包装为复杂的Chain和Tool，徒增心智负担。

于是，“Minimal Agent”的思路开始流行：只依赖大模型的函数调用（Function Calling）能力，配合极少的逻辑代码（甚至不到100行），就能实现同样的效果。

手搓核心：用Function Calling打通文件系统

所谓“手搓”，本质上并不神秘。其技术核心在于，利用大模型（如GPT-4、Claude等）原生支持的Function Calling API，将“读文件”、“写文件”、“目录遍历”、“代码搜索”等操作注册为“函数”或“工具”。当用户提出“帮我阅读这个项目”时，大模型会自主分析需求，并决定调用哪个函数。

例如，一个最简单的“手搓Agent”实现如下：

  1. 定义函数描述：通过JSON Schema告诉大模型，它可以使用read_file(path)获取文件内容，使用list_directory(path)查看文件夹结构，使用search_code(keyword)在项目中搜索特定代码片段。
  2. 调用与执行：用户提问后，大模型返回一个函数调用请求（而非直接回答问题）。开发者本地的脚本捕获这个请求，执行对应操作（比如读取README.md），并将结果作为新的消息返回给大模型。
  3. 迭代与总结：大模型拿到文件内容后，可能再次要求读取下一个文件或检查依赖关系，直到它认为自己拥有足够的信息，才开始生成最终的回答。

整个过程，没有Chain，没有Agent的类继承，没有复杂的回调机制，只有简单的循环和函数映射。有开发者公开过自己的实现：仅用不到80行Python代码，就构建了一个能自动分析项目结构、理解代码逻辑、发现潜在问题的Agent。

带来什么：透明、可控与极低的学习成本

这种“手搓”方式最大的优势是透明。每一轮交互中，大模型调用了哪个函数，传入了什么参数，返回了什么结果，开发者一目了然。在调试时，可以轻松打印出每一步的对话记录，精准定位问题。而LangChain等框架有时候会隐式处理这些细节，让开发者陷入“黑盒”困境。

此外，手搓Agent的学习门槛极低。如果开发者已经熟悉大模型API和基础Python，通常半天之内就能写出来。更重要的是，它可以灵活定制：想增加一个“通过SSH操作远程服务器”的功能？只需新增一个函数描述和一个实现函数即可。

现实意义：AI从未如此“接地气”

当AI拥有了“读文件的手”，很多应用场景立刻变得真切。例如，技术主管可以将新入职同事的代码仓库交给Agent，自动生成“代码摘要、架构分析和潜在Bug报告”；产品经理输入一个需求文档，Agent可以遍历整个项目，检查实现是否一致；开发者甚至可以让AI“观察”自己项目中遗留的TODO和FIXME，并生成变更建议。

当然，手搓方案并非万能。对于需要多步推理、记忆长上下文的任务，LangChain提供的工具链依然具备优势。但在大量的“轻度Agent”场景中，返璞归真的手搓方案，反而让AI更轻巧、更易用。正如一位开发者所说：“框架给了我们梯子，但有时候，我们需要的只是一双手。”

这场从“框架依赖”到“手搓实干”的回归，或许正预示着AI应用开发的新方向：让技术回归本质，让大模型不再高高在上，而是俯下身子，真正“动起手来”。