# 企业内网本地大模型落地教程：从私有知识库、代码审查到低风险 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. 最小可行架构

推荐先做单机或小组级试点，不要一开始上平台化大工程。

```text
内网用户
  │
  ├─ 浏览器：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 网络和安全边界

内网试点建议按以下方式切分：

```text
pilot-local-llm/
  models/          # 模型文件或拉取缓存，仅管理员可写
  docs/            # 试点文档，只放允许进入模型上下文的资料
  code-samples/    # 脱敏代码或指定试点仓库
  outputs/         # 模型输出报告，定期清理
  logs/            # 服务日志和审计记录
```

权限建议：

- `models/`：管理员写，用户只读
- `docs/`：业务负责人审核后写入
- `outputs/`：用户写，安全/项目负责人可读
- `logs/`：运维和安全团队可读

验收前不要接入：

- 生产数据库写权限
- `kubectl delete` / `helm upgrade` / `terraform apply` 等变更命令
- 企业微信、邮件、工单系统的自动发送权限
- 包含客户隐私、密钥、Token 的原始数据集

## 4. 场景一：内网私有文档问答

目标：让员工在不上传云端的前提下，对制度、合同、项目文档、故障复盘进行问答。

### 4.1 准备样例文档

创建一个最小样例目录：

```bash
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。
EOF
```

### 4.2 启动 Ollama 和文档问答工具

如果内网允许 Docker，可先用 AnythingLLM 做最小试点：

```bash
# 启动 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 下的文档
```

如果企业不允许直接联网拉镜像和模型，应改为：

```text
1. 在外网隔离下载区下载镜像和模型。
2. 安全团队完成文件校验与许可证检查。
3. 导入内网镜像仓库和模型仓库。
4. 试点机器只从内网仓库拉取。
```

### 4.3 测试问题

复制下面的问题进行验收：

```text
请根据已上传文档回答：
1. 生产数据库执行 DROP 或 TRUNCATE 前需要满足什么条件？
2. 2026-05 的锁等待事故暴露了什么流程问题？
3. 如果我要做一次批量 UPDATE，应该增加哪些保护措施？
请引用来源文档名称，不要编造文档中没有的制度。
```

预期输出形态：

```text
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 拉取代码模型

```bash
ollama pull qwen2.5-coder:7b
ollama run qwen2.5-coder:7b
```

### 5.2 准备审查提示词

将下面内容保存为 `pilot-local-llm/code_review_prompt.txt`：

```text
你是一名严厉的企业代码审查员。你的目标是找问题，不是鼓励作者。

只审查我提供的代码，不要猜测不存在的上下文。

重点检查：
1. 安全漏洞：SQL 注入、命令注入、权限绕过、敏感数据暴露。
2. 边界条件：空值、异常返回、超时、并发、重复执行。
3. 可维护性：过度复杂、隐式副作用、难以回滚。
4. 企业规范：禁止硬编码密码、Token、IP；生产脚本不要使用 shell=True。

输出格式：
- 高风险问题：
- 中风险问题：
- 建议修改：
- 需要人工确认的问题：

不要总结代码功能，直接输出发现的问题。
```

### 5.3 样例代码审查

保存样例文件：

```bash
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
```

交互式审查：

```bash
ollama run qwen2.5-coder:7b
```

然后粘贴：

```text
请按以下规则审查代码：

[粘贴 code_review_prompt.txt 内容]

代码：

[粘贴 user_query.py 内容]
```

预期发现：

```text
- 高风险问题：user_id 被直接拼接进 SQL，存在 SQL 注入风险。
- 中风险问题：SELECT * 可能暴露不必要字段。
- 中风险问题：用户不存在时返回 None，调用方可能在更深层位置报错。
- 建议修改：使用参数化查询；明确选择字段；对空结果抛出业务异常或返回显式状态。
```

### 5.4 接入 IDE

Continue 插件示例配置：

```json
{
  "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`：

```text
FROM llama3.2:3b

SYSTEM """
你是企业内网研发团队的本地审查助手。

团队背景：
- 主要使用 Python、SQL、Docker 和 Kubernetes。
- 关注生产安全、可回滚、可审计。
- 所有建议必须适合内网环境，不依赖外部 SaaS。

回答规则：
- 先给结论，再给理由。
- 不要输出 Markdown 表格。
- 不要建议上传代码、日志或业务文档到云端服务。
- 涉及生产变更时，必须要求人工确认和回滚方案。
- 不知道就说不知道，不要编造企业内部制度。
"""

PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER num_ctx 4096
```

创建模型：

```bash
ollama create team-reviewer -f pilot-local-llm/Modelfile.team-reviewer
ollama run team-reviewer
```

测试输入：

```text
我要把一个批量更新 SQL 交给你审查。你需要先检查哪些信息？
```

预期输出：

```text
结论：先确认影响范围、回滚方案、备份状态和执行窗口。

需要的信息：
1. SQL 原文和目标表。
2. WHERE 条件是否限定批次。
3. 预计影响行数。
4. 是否已有备份和回滚 SQL。
5. 是否有锁等待监控和执行超时策略。
```

验收标准：

- 回答符合团队固定规则。
- 不建议使用外部云服务。
- 遇到生产风险会主动要求人工确认。
- 改 Modelfile 后重新 `ollama create` 能稳定生效。

失败处理：

- 如果模型忘记团队约束：减少 SYSTEM 内容，只保留 5–8 条硬规则。
- 如果模型太保守：给出允许回答的范围，例如“只做审查建议，不执行命令”。
- 如果不同人维护多个版本：把 Modelfile 纳入内部 Git 仓库，走评审流程。

## 7. 场景四：只读型本地 Agent

目标：验证本地模型能否驱动一个小工具链完成“读资料 → 整理 → 写报告”的闭环。第一阶段不要让它改生产系统。

### 7.1 安装依赖

如果企业内网使用 Python 虚拟环境：

```bash
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`：

```python
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()
```

运行：

```bash
ollama serve
python pilot-local-llm/local_readonly_agent.py
```

预期输出文件：

```text
pilot-local-llm/outputs/db_change_checklist.md
```

预期内容形态：

```text
# 数据库变更执行前检查清单

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. 安全与合规检查清单

上线前逐项确认：

```text
[ ] 模型、镜像、插件来自企业允许来源。
[ ] 试点数据目录经过业务负责人确认。
[ ] 模型服务未暴露到不必要网段。
[ ] 用户权限按目录隔离，不共享个人敏感文件。
[ ] 日志不记录密钥、Token、客户隐私原文。
[ ] Agent 没有生产写权限。
[ ] 输出进入人工审核，不自动进入生产流程。
[ ] 已准备模型下线、服务关闭、数据清理步骤。
[ ] 已记录模型版本、提示词版本和关键配置。
```

## 10. 常见误区

### 误区一：一开始就做“企业级 AI 平台”

更好的做法：先用单机 Ollama + 明确目录 + 三个样例场景验证价值。平台化应在真实使用频率和风险边界清楚后再做。

### 误区二：把本地模型当成云端前沿模型替代品

本地 3B–7B 模型适合低风险、上下文明确、工具少的任务。复杂推理、多轮规划、跨系统自动变更仍需要更强模型或更严格人工审核。

### 误区三：只看模型效果，不看数据边界

企业内网本地模型的核心价值不是“更聪明”，而是数据不出内网、成本可控、可审计。权限和日志比模型排行榜更重要。

### 误区四：让 Agent 过早拥有写权限

只读 Agent 已经能带来价值：读文档、解释日志、生成检查清单、写报告。写生产系统必须等到验证、审批、回滚、审计都成熟后再考虑。

## 11. 最小验收表

```text
项目：企业内网本地大模型试点
周期：4 周
负责人：________
试点团队：________

验收项：
[ ] 本地模型服务可启动，版本可追溯。
[ ] 文档问答能引用来源，不编造制度。
[ ] 代码审查能发现至少 3 类明确问题。
[ ] 只读 Agent 输出报告，不越权读写。
[ ] 所有输出均有人工审核。
[ ] 已记录失败案例和处理方式。
[ ] 已明确下一阶段是否推广。

结论：
[ ] 继续扩大试点
[ ] 保持小范围使用
[ ] 暂停，补齐安全或效果问题
```

## 12. 推荐落地顺序

按风险从低到高推进：

1. 本地离线问答：个人或小组文档。
2. 内网私有知识库：受控文档目录 + RAG。
3. 本地代码审查：只读仓库 + 人工采纳。
4. 固定上下文助手：团队 Modelfile + 固定规则。
5. 只读 Agent：读资料、生成报告。
6. 半自动 Agent：生成候选命令或变更计划，但必须人工确认。
7. 自动执行：暂不建议作为第一阶段目标。

## 13. 管理层可读摘要

这类方案适合先做“小而可控”的企业内网 AI 能力：用本地模型处理内部文档、代码和报告，不把敏感数据发往云端。短期价值不是替代所有 AI 工具，而是在合规敏感场景中提供一个可审计、低成本、低权限的辅助层。第一阶段的成功标准不是模型多聪明，而是：数据边界清楚、输出可用、失败可控、权限不扩大。