今天，我想和大家分享一些我近期在企业内部署和应用AI大模型的实战经验。我们都习惯了使用Claude、ChatGPT等公网AI工具。但对于许多企业来说，研发数据和内部文档具有高度保密性，绝不可能上传到公网。那么，如何在保证数据安全的前提下，享受大模型带来的研发红利呢？我近期的工作，就是围绕这个问题展开的。过去，我的工作流主要依赖公网的大模型，比如Claude或CodeX，来辅助研发和文档工作。但当面临必须在内网处理保密数据时，AI的本地化部署就成了唯一的选择。
Part 1：从0到1的突破——为什么要在本地做Agent？
我们兄弟部门内部已经部署了 Deepseek R1 (671B) 这样强大的模型。在过去，我们使用它可能只是简单的文本对话。而我这几天的工作，就是实现一个从0到1的突破：让这个本地的Deepseek模型，具备自主使用工具（Agent）的能力。
我们不再通过浏览器访问，而是转向命令行的交互方式。在这种模式下，AI有一个强大的能力：它会自己分析任务，将其分解为子任务，并调用具体的工具链去执行，比如生成代码或分析文档。
我们具体是怎么做到的呢？利用 ClaudeCode 的 SubAgents 的能力，结合一个路由转换服务（比如LiteLLM），将客户端的请求指向了我们本地部署的Deepseek模型。这样，我们就等于让deepseek AI也具备了类似 anthropic 的 claude 的自主进行任务编排和工具调用的能力。
Part 2：AI的新能力——当模型拥有“手脚”
当这个链路打通后，AI不再只是一个“大脑”，它拥有了“手脚”，可以与你的电脑真实交互：
- 调用本地命令： 当我在命令行输入
ls，AI能理解我的意图是“列出当前目录文件”，它会主动调用本地的Shell命令并返回结果。 - 读写本地文件： 你可以要求它：“把这份报告总结成Markdown文档存下来”。它会立刻读取、分析、思考，然后将文本写入你本地的新文件。
- 自动化开发环境： 我们可以让AI帮我们配置环境。比如，你下达指令：“请帮我设置一个Python虚拟环境，并安装pandas”。AI会自动执行创建、激活、安装等一系列命令。这在以前是必须手动完成的。
Part 3：真实的挑战——使用本地Agent会遇到的三个“坑”
然而，打通链路只是第一步。在实际使用中，我们很快遇到了三个重大的短板，这也是大家未来一定会遇到的问题：
第一个坑：上下文窗口限制 (Token Limit) 我们本地模型的上下文长度（比如32K Token）是受限的。当你的对话轮次过多，它就会报错，导致任务中断。而商业工具（如Claude）具备“会话压缩”（Compact）能力，可以在后台自动总结历史对话，实现“无限续杯”。
第二个坑：AI的“幻觉”与“偷懒” 你会碰到一个问题：AI会“偷懒”。你让它帮你写一个项目模块，它可能会用虚假的方式应付你，回复说“我已经在生成了”、“我已完成”，但实际上它什么都没做。
第三个坑：代码混乱与冗余 如果你不加约束，在迭代修改时，AI会不断创建新文件，比如v1.py, v2.py，导致项目一团糟。
Part 4：我们的应对策略——如何成为AI“指挥官”
面对这些挑战，我们必须改变使用AI的模式。你的角色不再是“提问者”，而是“指挥官”。
第一：杜绝“大撒把”，精细化拆解任务 你绝不能把一个非常宏观的任务交给它，比如“帮我构建一个XX系统”。这必然会导致AI“胡编乱造”。
正确的做法是：
- AI辅助拆解： 让AI先把宏观任务拆解成“具体可实现的颗粒度”。
- 明确输入输出： 给你交给AI的每个任务，都明确定义“输入是什么”、“输出标准是什么”、“中间过程要遵循什么规范”。
第二：定义“AI人格”与Prompt约束 我们通过配置文件，来为AI设定“人格”（Agent）。你可以在文档里说明：“你是一个AI工程师”、“你必须遵循MVP（最小可行产品）规范，不要过度设计”、“你每完成一个函数，都要写git commit和README”。当你调用这个人格时，AI会严格遵照你的规范行事。
第三：养成“主动日志”的习惯 为了应对Token限制，你必须主动要求AI：“请把我刚才做的事情，以Markdown或Log日志的形式记录到本地”。当会话意外中断时，你可以关闭窗口，重开会话并让AI“先读取之前的log日志”，以此来恢复上下文。
第四：强制AI“在原地修改” 为了避免代码混乱，你必须明确要求它：“在已有的代码基础上做优化和修改”，而不是任其生成新文件。
一个全栈案例： 有人问我那个公寓管理系统是怎么实现的。那个项目，我几乎没有写过传统的业务逻辑代码。 我的思路是：首先，我用超大模型帮我输出一份分析报告，告诉我需要哪些模块。然后，我把这份报告扔给命令行的AI Agent（通过 ClaudeCode 客户端），让它分步骤实现前端、后端和数据库。所有代码的撰写、设置，甚至一键部署，都是AI生成的。
我的工作转变成了“指挥官”或“元开发者”：我负责提供高层级的架构分析报告、定义清晰的任务、验证AI的输出、并在出错时提供精确的错误日志引导它迭代。这是一种新的开发范式，我的“代码”就是这些高维度的指令和验证。
Part 5：混合模型策略——内网（RAG）与外网（Claude/Gemini）如何协同？
我们本地的Deepseek不具备联网能力，也不了解我们公司内部的知识，比如特定的生产环节文档或内部代码库。
这时，就必须结合RAG（检索增强生成）。在提问时，系统应主动检索内部知识库，把这些私有知识作为背景信息，一并提供给大模型。
但如果你面临的问题非常前沿，本地没有资源。我的建议是，你需要在可以联网的电脑上，使用第三方的超大模型，比如CodeX、Gemini或公网的Claude。这些万亿级参数的模型，在创新型研究上能提供巨大帮助。
我举个例子。我完全没有安卓开发经验，但我通过与AI的持续交互，让它一步步牵引我，包括环境设置、模型加载，最终在手机端跑通了一个包含ASR（语音识别）和翻译功能的原型App。
所以我鼓励大家采用一种混合策略：
- 调研阶段： 利用外部的万亿级模型进行深度的全面分析，掌握痛点和难点。
- 执行阶段： 把任务分解，转回到企业内网，利用我们千亿级的 Deepseek R1 模型，结合RAG去做细化的实现。
Part 6：未来展望——RAG 还是 Fine-tuning？
最后，我想厘清一个概念：RAG 和微调（Fine-tuning）的区别。
模型训练完成后，其内部参数是固定的，像被时光冻住一样。它不会因为你提供了新数据就学会新知识。
- 什么时候用 RAG？ 当你需要模型处理逻辑推理和海量新知识时（比如复杂的故障分析）。超大模型（例如先进的8B到70B模型，乃至我们这个671B的模型）已具备强大的底层逻辑理解能力，它缺的只是你的领域知识。你通过RAG（外挂知识库）的方式，把新知识作为“上下文”喂给它，这是最高效的路径。
- 什么时候用微调（Fine-tuning）？ 当你有一个非常专一、目标明确、高度重复的场景。比如，我需要一个AI只做一件事：自动分类。当一篇新文档被上传，AI读取前100行，自动判断它属于工厂里的哪一个知识库目录。这种任务就非常适合微调一个小模型，它会做得非常准确高效。
结束语
总而言之，我这几天的工作，是把本地AI的工具调用能力从0到1建立了起来。如果你发现你的AI无法做到这些，那很可能是因为你用的是浏览器的对话版，它不具备工具调用能力。而通过 ClaudeCode 这样的客户端，我们释放了 Deepseek R1 这样的本地大模型真正的潜力。
但从1到N，我们还有很多挑战，比如上下文长度、模型幻觉、配置优化等。这需要我们研发人员转变思路，真正把AI当作“结对编程”的伙伴，不断积累经验，优化我们的工具链。