企业内网本地大模型落地教程:从私有知识库、代码审查到低风险 Agent
> 基于文章《5 Cool Things I Did with Local Language Models》提炼,并面向企业内网环境改写。本文不是逐字翻译,而是把原文的 5 个本地模型用例改造成企业可试点、可验收、可回滚的落地教程。
- 原文: https://www.kdnuggets.com/5-cool-things-i-did-with-local-language-models
- 本地总结路径:
/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260519-151908-5-Cool-Things-I-Did-with-Local-Language-Models-2578173-232978520-summary.md - 适用范围:内网研发团队、数据团队、运维团队、安全合规要求较高的业务部门
- 不适用范围:要求强复杂推理、自动变更生产系统、无人工确认的全自动决策场景
1. 一句话结论
企业内网落地本地大模型,第一阶段不要追求“通用智能助手”,而应从三个低风险场景开始:私有文档问答、代码审查助手、只读型自动化 Agent。这三类场景数据不出内网、成本可控、容易验收,也能快速暴露模型能力边界。
2. 最小可行架构
推荐先做单机或小组级试点,不要一开始上平台化大工程。
内网用户
│
├─ 浏览器:AnythingLLM / Open WebUI / 内部 Web 页面
├─ IDE:Continue / JetBrains 插件 / VS Code 插件
└─ 脚本:Python OpenAI-compatible client
│
▼
本地/内网推理服务:Ollama,监听 http://localhost:11434 或内网固定地址
│
├─ 文档问答模型:llama3.2:3b / mistral:7b
├─ 代码模型:qwen2.5-coder:7b
└─ Agent 决策模型:llama3.2:3b / mistral:7b-instruct
│
▼
受控数据区
├─ 文档目录:制度、合同、项目文档、知识库导出
├─ 代码目录:当前仓库或脱敏样例
└─ 工具目录:只读搜索、写入临时文件、生成报告第一阶段的关键约束:
- 模型只访问试点目录,不访问全盘文件。
- Agent 只允许读文件、搜索内网文档、写报告,不允许执行生产变更。
- 所有输出先进入人工审核,不直接写入生产库、工单系统或代码仓库主分支。
- 所有模型、插件、镜像和依赖都必须从企业允许的软件源或离线包安装。
3. 试点前准备
3.1 硬件建议
最低可试点配置:
- CPU:普通 x86_64 或 ARM64 均可
- 内存:16GB 更稳,8GB 只能跑小模型和小文档集
- GPU:不是必需;有 NVIDIA GPU 会明显加速
- 磁盘:至少预留 30GB,用于模型、向量库和文档缓存
模型选择建议:
- 文档问答:
llama3.2:3b起步,mistral:7b用于更强综合能力 - 代码审查:
qwen2.5-coder:7b - 简单 Agent:
llama3.2:3b或mistral:7b
3.2 网络和安全边界
内网试点建议按以下方式切分:
pilot-local-llm/
models/ # 模型文件或拉取缓存,仅管理员可写
docs/ # 试点文档,只放允许进入模型上下文的资料
code-samples/ # 脱敏代码或指定试点仓库
outputs/ # 模型输出报告,定期清理
logs/ # 服务日志和审计记录权限建议:
models/:管理员写,用户只读docs/:业务负责人审核后写入outputs/:用户写,安全/项目负责人可读logs/:运维和安全团队可读
验收前不要接入:
- 生产数据库写权限
kubectl delete/helm upgrade/terraform apply等变更命令- 企业微信、邮件、工单系统的自动发送权限
- 包含客户隐私、密钥、Token 的原始数据集
4. 场景一:内网私有文档问答
目标:让员工在不上传云端的前提下,对制度、合同、项目文档、故障复盘进行问答。
4.1 准备样例文档
创建一个最小样例目录:
mkdir -p pilot-local-llm/docs
cat > pilot-local-llm/docs/change_policy.md <<'EOF'
# 数据库变更规范
1. 所有 DDL 必须提前评审。
2. 涉及 DROP、TRUNCATE、批量 UPDATE 的 SQL 必须提供回滚方案。
3. 生产执行前必须完成备份。
4. 变更完成后需要归档 SQL、执行日志和负责人。
EOF
cat > pilot-local-llm/docs/incident_review.md <<'EOF'
# 2026-05 数据库锁等待复盘
问题:一次批量 UPDATE 未限制批次大小,导致锁等待增加。
影响:业务查询延迟升高 20 分钟。
改进:后续批量更新必须分批执行,并监控 pg_locks。
EOF4.2 启动 Ollama 和文档问答工具
如果内网允许 Docker,可先用 AnythingLLM 做最小试点:
# 启动 AnythingLLM
# 注意:企业内网环境中,镜像应从内部镜像仓库拉取;这里用公网镜像名只是示例。
docker run -d \
--name anythingllm \
-p 3001:3001 \
-v anythingllm_storage:/app/server/storage \
mintplexlabs/anythingllm
# 准备本地模型
ollama pull llama3.2:3b
# 打开 http://localhost:3001
# 在 AnythingLLM 中连接 Ollama: http://host.docker.internal:11434 或实际内网地址
# 上传 pilot-local-llm/docs 下的文档如果企业不允许直接联网拉镜像和模型,应改为:
1. 在外网隔离下载区下载镜像和模型。
2. 安全团队完成文件校验与许可证检查。
3. 导入内网镜像仓库和模型仓库。
4. 试点机器只从内网仓库拉取。4.3 测试问题
复制下面的问题进行验收:
请根据已上传文档回答:
1. 生产数据库执行 DROP 或 TRUNCATE 前需要满足什么条件?
2. 2026-05 的锁等待事故暴露了什么流程问题?
3. 如果我要做一次批量 UPDATE,应该增加哪些保护措施?
请引用来源文档名称,不要编造文档中没有的制度。预期输出形态:
1. DROP/TRUNCATE 前需要提前评审,并提供回滚方案;生产执行前需要备份。来源:change_policy.md。
2. 锁等待事故暴露出批量 UPDATE 未限制批次大小的问题。来源:incident_review.md。
3. 建议分批执行、监控 pg_locks、归档执行日志。来源:incident_review.md 与 change_policy.md。验收标准:
- 能引用正确文档名。
- 不把未上传的制度当成事实。
- 对不在文档中的问题明确回答“文档中没有说明”。
- 回答中不泄露其他目录文件内容。
失败处理:
- 如果回答混入无关内容:减少上传文档数量,重新建索引。
- 如果引用错误:检查切分策略和文档标题;优先使用 Markdown 或纯文本。
- 如果速度太慢:先换
llama3.2:3b,减少单次检索片段数量。 - 如果答案过度自信:在系统提示中加入“只基于检索内容回答,不足则说不知道”。
5. 场景二:内网代码审查助手
目标:让开发者在不上传业务代码到云端的情况下,获得安全、边界条件、复杂度方面的初步审查。
5.1 拉取代码模型
ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b5.2 准备审查提示词
将下面内容保存为 pilot-local-llm/code_review_prompt.txt:
你是一名严厉的企业代码审查员。你的目标是找问题,不是鼓励作者。
只审查我提供的代码,不要猜测不存在的上下文。
重点检查:
1. 安全漏洞:SQL 注入、命令注入、权限绕过、敏感数据暴露。
2. 边界条件:空值、异常返回、超时、并发、重复执行。
3. 可维护性:过度复杂、隐式副作用、难以回滚。
4. 企业规范:禁止硬编码密码、Token、IP;生产脚本不要使用 shell=True。
输出格式:
- 高风险问题:
- 中风险问题:
- 建议修改:
- 需要人工确认的问题:
不要总结代码功能,直接输出发现的问题。5.3 样例代码审查
保存样例文件:
mkdir -p pilot-local-llm/code-samples
cat > pilot-local-llm/code-samples/user_query.py <<'EOF'
def get_user_data(user_id):
query = f"SELECT * FROM users WHERE id = {user_id}"
result = db.execute(query)
return result.fetchone()
EOF交互式审查:
ollama run qwen2.5-coder:7b然后粘贴:
请按以下规则审查代码:
[粘贴 code_review_prompt.txt 内容]
代码:
[粘贴 user_query.py 内容]预期发现:
- 高风险问题:user_id 被直接拼接进 SQL,存在 SQL 注入风险。
- 中风险问题:SELECT * 可能暴露不必要字段。
- 中风险问题:用户不存在时返回 None,调用方可能在更深层位置报错。
- 建议修改:使用参数化查询;明确选择字段;对空结果抛出业务异常或返回显式状态。5.4 接入 IDE
Continue 插件示例配置:
{
"models": [
{
"title": "Qwen2.5-Coder Local",
"provider": "ollama",
"model": "qwen2.5-coder:7b",
"apiBase": "http://localhost:11434"
}
]
}企业内网注意点:
- 插件必须来自企业允许的软件分发源。
- 禁止插件同时配置云端模型和本地模型,避免误发代码。
- 首次试点只允许审查脱敏代码或指定仓库目录。
- 审查结果不得自动提交,只能作为 Merge Request / Pull Request 前的人工参考。
验收标准:
- 能识别明显 SQL 注入、硬编码密钥、
shell=True等问题。 - 对不存在的上下文不编造结论。
- 审查输出能区分高/中/低风险。
- 开发者能把至少一条建议转化为真实代码修改。
失败处理:
- 如果模型只夸代码:强化系统提示中的“目标是找问题”。
- 如果模型输出太长:限制输出为“最多 8 条发现”。
- 如果模型改动建议不可执行:要求它输出最小 diff 或只给伪代码。
- 如果误报太多:把审查范围缩小到安全漏洞和边界条件。
6. 场景三:个人/团队固定上下文助手
目标:把团队背景、代码规范、输出偏好固化到本地模型,减少每次对话重复解释。
6.1 创建团队 Modelfile
保存为 pilot-local-llm/Modelfile.team-reviewer:
FROM llama3.2:3b
SYSTEM """
你是企业内网研发团队的本地审查助手。
团队背景:
- 主要使用 Python、SQL、Docker 和 Kubernetes。
- 关注生产安全、可回滚、可审计。
- 所有建议必须适合内网环境,不依赖外部 SaaS。
回答规则:
- 先给结论,再给理由。
- 不要输出 Markdown 表格。
- 不要建议上传代码、日志或业务文档到云端服务。
- 涉及生产变更时,必须要求人工确认和回滚方案。
- 不知道就说不知道,不要编造企业内部制度。
"""
PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER num_ctx 4096创建模型:
ollama create team-reviewer -f pilot-local-llm/Modelfile.team-reviewer
ollama run team-reviewer测试输入:
我要把一个批量更新 SQL 交给你审查。你需要先检查哪些信息?预期输出:
结论:先确认影响范围、回滚方案、备份状态和执行窗口。
需要的信息:
1. SQL 原文和目标表。
2. WHERE 条件是否限定批次。
3. 预计影响行数。
4. 是否已有备份和回滚 SQL。
5. 是否有锁等待监控和执行超时策略。验收标准:
- 回答符合团队固定规则。
- 不建议使用外部云服务。
- 遇到生产风险会主动要求人工确认。
- 改 Modelfile 后重新
ollama create能稳定生效。
失败处理:
- 如果模型忘记团队约束:减少 SYSTEM 内容,只保留 5–8 条硬规则。
- 如果模型太保守:给出允许回答的范围,例如“只做审查建议,不执行命令”。
- 如果不同人维护多个版本:把 Modelfile 纳入内部 Git 仓库,走评审流程。
7. 场景四:只读型本地 Agent
目标:验证本地模型能否驱动一个小工具链完成“读资料 → 整理 → 写报告”的闭环。第一阶段不要让它改生产系统。
7.1 安装依赖
如果企业内网使用 Python 虚拟环境:
python3 -m venv pilot-local-llm/.venv
source pilot-local-llm/.venv/bin/activate
pip install openai如果不能访问公网 PyPI,应从企业内部 PyPI 镜像安装。
7.2 准备只读 Agent 脚本
保存为 pilot-local-llm/local_readonly_agent.py:
from __future__ import annotations
from pathlib import Path
from openai import OpenAI
BASE_DIR = Path("pilot-local-llm/docs").resolve()
OUTPUT_DIR = Path("pilot-local-llm/outputs").resolve()
OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
MODEL = "llama3.2:3b"
def read_doc(filename: str) -> str:
path = (BASE_DIR / filename).resolve()
if not str(path).startswith(str(BASE_DIR)):
return "拒绝访问:文件路径越界。"
if not path.exists():
return f"文件不存在:{filename}"
return path.read_text(encoding="utf-8")
def write_report(filename: str, content: str) -> str:
path = (OUTPUT_DIR / filename).resolve()
if not str(path).startswith(str(OUTPUT_DIR)):
return "拒绝写入:文件路径越界。"
path.write_text(content, encoding="utf-8")
return f"报告已写入:{path}"
def summarize_policy() -> None:
source = read_doc("change_policy.md") + "\n\n" + read_doc("incident_review.md")
prompt = f"""
你是内网审查助手。请只基于以下资料生成一份执行前检查清单。
要求:
- 不要编造资料外制度。
- 输出 6 条以内。
- 标出需要人工确认的项目。
资料:
{source}
"""
response = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": prompt}],
)
content = response.choices[0].message.content or ""
print(write_report("db_change_checklist.md", content))
if __name__ == "__main__":
summarize_policy()运行:
ollama serve
python pilot-local-llm/local_readonly_agent.py预期输出文件:
pilot-local-llm/outputs/db_change_checklist.md预期内容形态:
# 数据库变更执行前检查清单
1. 是否已完成 DDL 或高风险 SQL 评审。
2. 是否提供 DROP、TRUNCATE、批量 UPDATE 的回滚方案。
3. 是否已完成生产备份。
4. 批量 UPDATE 是否限制批次大小。
5. 是否监控 pg_locks 或等价锁等待指标。
6. 是否归档 SQL、执行日志和负责人。验收标准:
- Agent 只能读
pilot-local-llm/docs。 - Agent 只能写
pilot-local-llm/outputs。 - 输出内容能追溯到样例文档。
- 不调用外部网络,不执行系统变更命令。
失败处理:
- 如果脚本访问越界:立即停止试点,修复路径校验。
- 如果模型编造制度:在 prompt 中加入“每条检查项必须来自资料原文”。
- 如果输出不可复现:降低 temperature,固定模型版本,保存输入和输出日志。
- 如果要接入真实工具:先增加人工确认步骤,不要直接执行写库、发消息、改配置。
8. 企业内网推广路线
第 1 周:单机验证
目标:证明模型可运行、数据不出机器、输出有基本价值。
任务:
- 准备 10–20 篇内部非敏感文档。
- 跑通 AnythingLLM 或等价本地 RAG 工具。
- 跑通
qwen2.5-coder:7b对样例代码审查。 - 跑通只读 Agent 写报告。
交付物:
- 模型清单和版本。
- 数据目录权限说明。
- 3 份样例输出。
- 已知失败案例列表。
第 2 周:小组试点
目标:验证真实用户是否愿意用,输出是否能转化为工作结果。
任务:
- 选择 3–5 名研发或运维用户。
- 每人提交 2 个真实但低风险问题。
- 记录模型答案、人工修正、节省时间、误报情况。
验收标准:
- 至少 60% 的回答被用户认为“可作为初稿”。
- 不出现敏感数据越权读取。
- 不出现模型自动执行生产变更。
- 用户能明确说出 1–2 个继续使用的场景。
第 3 周:制度化边界
目标:把试点经验固化为企业内部使用规则。
需要形成:
- 允许使用的数据类型清单。
- 禁止输入的数据类型清单。
- 模型输出免责声明。
- 人工审核要求。
- 日志保留与清理策略。
- 模型升级和回滚流程。
第 4 周:有限推广
目标:把成功场景推广到更多团队,但不扩大权限。
推荐只推广:
- 文档问答
- 代码审查建议
- 报告初稿生成
- 只读巡检结果解释
暂不推广:
- 自动改生产配置
- 自动执行数据库变更
- 自动关闭告警
- 自动发正式通知
- 自动合并代码
9. 安全与合规检查清单
上线前逐项确认:
[ ] 模型、镜像、插件来自企业允许来源。
[ ] 试点数据目录经过业务负责人确认。
[ ] 模型服务未暴露到不必要网段。
[ ] 用户权限按目录隔离,不共享个人敏感文件。
[ ] 日志不记录密钥、Token、客户隐私原文。
[ ] Agent 没有生产写权限。
[ ] 输出进入人工审核,不自动进入生产流程。
[ ] 已准备模型下线、服务关闭、数据清理步骤。
[ ] 已记录模型版本、提示词版本和关键配置。10. 常见误区
误区一:一开始就做“企业级 AI 平台”
更好的做法:先用单机 Ollama + 明确目录 + 三个样例场景验证价值。平台化应在真实使用频率和风险边界清楚后再做。
误区二:把本地模型当成云端前沿模型替代品
本地 3B–7B 模型适合低风险、上下文明确、工具少的任务。复杂推理、多轮规划、跨系统自动变更仍需要更强模型或更严格人工审核。
误区三:只看模型效果,不看数据边界
企业内网本地模型的核心价值不是“更聪明”,而是数据不出内网、成本可控、可审计。权限和日志比模型排行榜更重要。
误区四:让 Agent 过早拥有写权限
只读 Agent 已经能带来价值:读文档、解释日志、生成检查清单、写报告。写生产系统必须等到验证、审批、回滚、审计都成熟后再考虑。
11. 最小验收表
项目:企业内网本地大模型试点
周期:4 周
负责人:________
试点团队:________
验收项:
[ ] 本地模型服务可启动,版本可追溯。
[ ] 文档问答能引用来源,不编造制度。
[ ] 代码审查能发现至少 3 类明确问题。
[ ] 只读 Agent 输出报告,不越权读写。
[ ] 所有输出均有人工审核。
[ ] 已记录失败案例和处理方式。
[ ] 已明确下一阶段是否推广。
结论:
[ ] 继续扩大试点
[ ] 保持小范围使用
[ ] 暂停,补齐安全或效果问题12. 推荐落地顺序
按风险从低到高推进:
1. 本地离线问答:个人或小组文档。 2. 内网私有知识库:受控文档目录 + RAG。 3. 本地代码审查:只读仓库 + 人工采纳。 4. 固定上下文助手:团队 Modelfile + 固定规则。 5. 只读 Agent:读资料、生成报告。 6. 半自动 Agent:生成候选命令或变更计划,但必须人工确认。 7. 自动执行:暂不建议作为第一阶段目标。
13. 管理层可读摘要
这类方案适合先做“小而可控”的企业内网 AI 能力:用本地模型处理内部文档、代码和报告,不把敏感数据发往云端。短期价值不是替代所有 AI 工具,而是在合规敏感场景中提供一个可审计、低成本、低权限的辅助层。第一阶段的成功标准不是模型多聪明,而是:数据边界清楚、输出可用、失败可控、权限不扩大。