企业官网建设流程全解析

最近的动静有点意思：某一线软件厂商准备把 137B 参数规模的代码模型完整搬到 PC 端来做端侧推理。137B 是什么概念？1370 亿参数，搁两年前这个量级还只能窝在机房里，借着几卡互相连起来才能跑得动。现在却已经有人开始讨论它在普通开发者的本机、工位上、甚至一台称不上服务器的电脑里稳定输出、持续干活。

比“跑起来”更值得聊的，是后半句话：模型一旦能写入本地文件、调用工具、替用户执行命令，它就不是一个问答机，而是一个 Agent。这个 Agent 会在你的电脑上动手改文件、用了查日志、试着重跑构建、甚至直接调你的测试环境。这时候真正麻烦的问题不是“它会不会回答错”，而是“它有没有权限做错事”“它被授权做的事，会不会把系统弄得一团糟”。所以这次我不打算只聊模型精度和量化，再来一次完整把重点落到两端：一端是端侧推理怎么实际落地，另一端是 Agent 权限防线怎么从原理到配置一步一步搭起来。整篇内容更适合那些在本地跑过大模型、想继续往上做 Agent 开发的工程师，以及正准备给自家编码工具加“自动化执行”能力的安全负责人。

1. 为什么要死磕端侧推理：编码模型下放 PC 的底层逻辑

1.1 云端推理解决不了的三类问题

先泼一句冷水：如果把代码模型继续放云端，也不是不能用，但你会发现三个让人很难受的短板。

第一个是数据边界。代码语义和补全建议往往要输入整个文件、甚至多文件上下文。对个人项目来说无所谓，可对企业开发环境来说，把核心仓库整段丢给云上推理服务，意味着代码资产在物理上离开了你的可控范围。哪怕服务方在协议里写了“不留存”，这道信任裂缝始终存在。而端侧推理的吸引力就在这：模型权重住在本机，推理发生在本机，上下文只存在于内存里，没有任何一段代码需要跨出这台 PC。

第二个是稳定性和延迟。编码工具是给开发者的交互体感用的，如果每次补全是 200ms 起步，其实还可以忍；但如果模型被很多用户共享、排队、回源重试，不稳定就是常态。端侧模式下首 token 延迟完全受本机算力控制，不会因为别人把页面流量打满了，就轮到你也要跟着慢慢等。对 Agent 来说这条更重要，因为 Agent 不是只调用一次推理，它往往是一个循环：推理想法、执行工具、看结果、再推理。一次循环多几百毫秒，整条链路的体感就纸一样脆弱。

第三个是成本。137B 参数量级的模型，按 token 计算服务成本持续使用并不低。如果你是做桌面工具、IDE 插件，要把此功能卖给大量用户，你不可能替每个用户兜住这笔云推理费。把模型丢上用户本机，推理成本从“按 token 付费”变成“一次性换硬件”，这对产品商业模型是更健康的重构。

1.2 算力账本：137B 不是拿来跑步的，它是拿来干活的

说到“搬到 PC”，很多人的第一反应是我的电脑扛不扛得住。要负责地说：扛得住，但前提是你得给它一个合理的工作方式，而不是拿它当云端万卡场景的缩小版。

端侧部署和服务器部署有一个本质区别：服务器追求的是高吞吐、多人并发、极致批处理；PC 追求的是低延迟、持续可用、单用户通勤。137B 模型在端上没法通过堆八卡来暴力提高性能，所以真正要思考的不是把模型“塞”进显存，而是让模型在内存够用、算子尽量加速的条件下稳定输出。我自己的经验是：把 137B 当“单人实时助手”来跑，远比把它当作“本地小号推理集群”来跑更容易成功。节奏放慢一点，使用 4bit 量化，把目光盯在“每次输出质量”和“执行安全”上，这套组合反而比单纯追求跑满整卡速度更适合真实开发场景。

1.3 端侧带来的新玩法：从补全到带权限的 Agent

模型落到本机，最先解锁的是“自由”。你不必再担心把内部代码上传到不可控的服务上，自然就可以把更大范围的上下文喂给模型：当前分支的差异、编译报错、内部组件文档、自动化测试输出。我们可以在一个完全断网的环境里，让模型读透整个项目的结构，再根据一条自然语言指令去完成任务。这种能力就是 Agent 的前提。

但“自由”永远伴随约束需求。Agent 会打开终端、读取文件、运行命令，这意味着它的权限边界必须被重新设计。你不能，也不该把 Agent 当作一个“带联网能力的补全框”。它一旦拥有资资源，就必须被当成系统中一个可信但不可全信的执行单元来治理。

2. 端侧推理落地的关键路径：从模型体重到推理引擎匹配

2.1 先把模型体积算明白

在动手之前，我建议每个人都先做一道算术题。137B 参数模型的全精度权重，如果按 16bit 存储，每个参数占 2 字节，那么总大小是：

137 × 10^9 × 2 字节 ≈ 274GB

这基本就是一台普通工作站的内存总量，算完就劝退了。如果按 8bit 量化，权重降到约 137GB，依然很庞大，但已经开始出现在高端台式机的内存范围内。真正让端侧成为可能的是 4bit 量化，权重体积会降到参数量的约 0.5~0.6 字节，也就是 70GB 上下的权重占用。

所以我们在“能跑”和“能舒服跑”之间，先要更新一个认知：决定性资源不只是“显存多大”，而是“整机内存/统一内存有多大”，因为大模型推理不仅是权重放不下就需要开 CPU 内存交换，而且 KV Cache 还要再吃一大块内存。

2.2 量化的取舍：不是越省越好

现在社区里常见的量化方案，思路都是尽量把权重数值的冗余压缩掉。主要分两类：训练后量化（PTQ）和需要少量校准数据的量化。前者跑起来快，部署简单；后者需要你把一小批代码样本喂进去，换来的是更合理的激活分布，减少量化带来的质量损失。

我给编码模型做端侧化时的偏好，是选择 4bit 附近、分组量化策略偏保守的格式。为什么不用 2bit 之类的更极限方案？因为代码生成太讲求准确性，一个符号错了就可能让整个测试失败。4bit 是目前权衡得比较好的档位，精度损失在可接受范围内，内存占用又足够让人在 PC 上部署。如果你机器内存较富余，用 5bit 或 6bit 混合层数分配，质量还会更好一点。核心心法是：不要为“能塞进内存”去做极限压缩，省出来的那几 GB，可能会变成你排查乱码和逻辑错误的时间。

2.3 推理引擎配置：别只盯着第一次 token 输出

模型落地还需要一个推理运行时，市面上几种常用推理框架各有侧重，核心指标有三个：加载速度、首 token 延迟、生成速度。对代码补全场景，首 token 延迟和生成速度同样重要；对 Agent 场景，你还得关心它是否支持持续对话、工具调用的结果注入、上下文滑动等特性。

我在实际部署中常用的思路，是让大部分计算落在 GPU 上，必要时把部分层留在 CPU 上。你可以先让模型加载完成后，通过日志查看每一层的分布，然后尽可能提升 GPU 层的比例。对 137B 量化模型来说，如果显卡显存不够，就得一层一层往 CPU 挪。一开始不要太贪，达到“输出稳定、不卡死”优先，再逐渐增加 GPU 层数，直到性能与内存占用达到平衡点。

2.4 KV Cache：那个容易被忽略的内存怪兽

讲一个连老手都可能看走眼的点：模型权重大不等于总内存需求，KV Cache 才是端侧推理的隐形吞噬者。

KV Cache 是为了避免每次生成时重复计算历史 token 而缓存下来的中间状态。上下文越长，KV Cache 越大。以一个约 80 层、KV 头较多的大模型为例，每个历史 token 大约会吃掉 1~1.5MB 内存。如果我把上下文窗口设置到 32K，KV Cache 可能就有 30~45GB。你没看错，权重一片 70GB 的模型，上下文要 32K 长，总的内存占用可能直接破百 GB。

这也是为什么很多讨论讲“137B 在 PC 上跑得动”，最后又补一句“但只适合短上下文”。要在 PC 上舒服使用，长需求要适度压上下文窗口，或者用“上下文压缩”“滑动窗口”“KV 量化”等方案来节省内存。我个人建议先按 4K~16K 来用，对绝大多数代码文件不缺失，内存压力也能小非常多。

3. Agent 权限防线：模型能干活，但不能乱干活

3.1 从一个具体场景聊权限问题

假设我已经把 137B 模型部署在 PC 上，然后接了一个自动化 Agent。它拿到你的指令是：“检查项目里的测试失败原因，如果发现是配置文件问题，直接修好它。”

这个任务听起来美好。但在我真实测试中，Agent 可能执行的路径是：先读取日志，再发现配置文件里有一处路径写错，于是它调用了文件修改工具，准备把错误路径替换。如果权限边界设计得不好，这个“修改工具”很可能会被调用到工作目录之外的文件上。比如说，它因为读到了你的日志路径，就想顺手改一下你存放在其他目录的系统级配置，而那个文件不应该有任何自动化程序去碰。

这个场景说明一件事：权限防线不是因为模型“有恶意”才需要，而是因为模型“可能理解错边界”才需要。

Agent 不是人类。人类拿到命令，会依靠常识判断“改哪些文件可以，哪些明确不该碰”。模型尽管经过了大量训练，但它终究没有全知常识，它对“项目边界”的理解经常是模糊的。你的目录结构、系统配置文件、组织者权限，这些概念在一个单纯的对话模型中压根没有实体对应物。所以我们必须把“边界”翻译成计算机能识别的权限规则。

3.2 最小权限原则：给 Agent 的能力做减法

权限设计最重要的一条原则，我称为“最小权限原则的 Agent 化表达”：Agent 只能调用完成任务所必需的工具，只能访问它所涉及的数据，只能执行被允许的操作，其他一切默认拒绝。

具体到实现上，通常需要把 Agent 能使用的“工具”先枚举出来。在我自己的部署里，我把它做成了一个“工具注册表”，而不是让 Agent 通过终端自由发挥。注册表里每项工具都要声明它做什么、需要哪些参数、会接触到哪些资源。随后，每项工具还要分一个权限等级：

• 可自动执行：只读类操作，比如读文件、搜索代码、看日志。
• 需要确认：会产生改动，但风险可控，比如写文件、改配置、执行测试。
• 默认禁止：高风险或不可逆操作，比如删目录、改系统服务、装包、向远端推送代码。
• 黑名单绝对禁止：比如 sudo、rm -rf /、直接格式化盘符等。

这份声明不仅是给 Agent 看的，也是给用户和安全审计看的。没有工具清单，就没有权限模型的基础。越早把 Agent 的工具集显式化，后面防线就越容易砌厚。

3.3 四条防线具体怎么搭：隔离、授权、审计、熔断

权限不是一个开关，它应该是一套纵深防御结构。我在实际操作中会搭四层，每一层解决不同的问题。

第一层是隔离。把 Agent 可以碰到的东西限制在一个沙箱里。最简单的方法是在系统里创建一个容器或专用目录，把项目的代码仓库挂载进去，再把必要的临时目录映射进去，除此之外，Agent 程序永远看不到宿主机的完整文件系统。这个做法特别有用，因为即使 Agent 想跑越权命令，它在容器里也找不到宿主系统关键文件。隔离的意义不是“别让它跑错”，而是“就算跑错，损失也可控”。

第二层是授权。每个工具调用都要经过能力检查。我把 Agent 的工具调用路径设计成“请求-检查-执行”三步：Agent 只是发出“我想用 write_file 写这个路径”的请求；授权服务会把这个请求和工具注册表里的规则做比对；通过后才真正改文件。这样一来，模型只能“建议做什么”，而不能“真的做什么”，真正的执行权在一个独立进程手里。

第三层是审计。每一条危险操作都会被记录下来：谁调用了哪个工具、传了什么参数、发生在什么时间、最终影响哪个文件。为了这层靠得住，日志不只是给人看的表格，它应该能回溯一次 Agent 的所有动作序列，这样当出现问题时，我们才能知道是哪一步决策开始跑偏的。

第四层是熔断。系统要能识别出“连续执行了大量改动”“删除了多个文件”“频繁访问不熟悉的网络地址”这类模式，达到阈值后主动暂停 Agent，要求人工确认。这个能力在 Agent 场景里特别重要，因为模型一旦陷入循环，它会重复一个错误行为，直到把磁盘填满或者把文件改坏。熔断机制就是给机器上一个保险丝。

3.4 模型与执行层之间的权责分工

做权限防线，本质上是在模型和执行层之间插进一个独立控制层。不用指望模型自己“自觉不搞破坏”，也不要去修改模型的输出来指导安全。正确的分工是：

模型负责“意图理解”，给出下一步建议。它看到报错日志，判断可能是配置错误，于是建议“修改某路径下的配置文件”。执行层负责“动作合法性判断”，它接到建议后，看这个路径是否在项目空间内、是否在白名单工具集中、是否需要用户确认。如果一切合规，才执行。

这个分工一旦确立，你会发现很多问题迎刃而解。模型输出错误文本并不可怕，因为执行层可以在动手前拦下非法调用。反过来，过严的权限也不会把模型彻底束缚住，因为普通开发任务的工具调用往往都在白名单里。那层防线真正的价值，是给模型“脱缰”的可能性留了一个物理刹车。

4. 一次完整实操记录：本地 137B 模型接 Agent 的部署过程

4.1 环境准备与模型获取

我这次部署用了一台 128GB 统一内存的工作站，显卡为独立 GPU 显存 24GB，系统是普通桌面 Linux 发行版，没有做任何集群扩展。模型选用某厂商的 137B 代码模型量化版，4bit 量化后权重文件约 70GB。

拿到模型后，我先做了一次完整性校验，然后把它放进一个独立的模型目录。证书和路径这类东西别偷懒，直接一步到位放整齐，后面排查问题会少很多痛苦。强烈建议不要放在系统盘中，模型文件非常大，系统盘 I/O 会被持续拖慢。

4.2 推理参数与首轮实测

这一步我用了一个常见推理框架的本地后端，加载时指定了上下文窗口为 16K，GPU 层数先设置为满负荷上限，剩余层交给 CPU。启动命令大致如下：

./run-model --model /models/code137b-q4.bin --gpu-layers 45 --ctx-size 16384 --threads 16 --temp 0.2

实测结果让我印象很深：加载阶段大约耗时近一分钟，属于正常范围；首 token 延迟大概在 0.8 秒左右；生成速度稳定在 20~30 tokens/s。这个速度对交互式补全来说已经可用，对后台处理任务来说更是绰绰有余。

有读者可能会问，为什么温度这么低？对代码生成任务，我习惯用 0.2 以下的温度，因为让模型多一点点保守，少一些“创造性发挥”，它的语法更稳。用高温度跑代码模型，很容易得到“看起来通顺但实际逻辑错误”的代码。

4.3 沙箱容器与 Agent 工具注册表

模型稳定跑起来之后，我开始搭 Agent。先建立一个容器，把项目目录挂载进去：

podman run -d --name code-agent \ -v /workspace/project:/project:rw \ -v /tmp/agent-cache:/cache:rw \ --network restricted \ --pids-limit 256 \ local-agent-image

这里的关键是“只挂载两个目录”，除此之外容器内没有任何宿主文件系统的访问权。网络被限制为 restricted 模式，只有白名单地址能访问。pids 限制也是为了防住 Agent 循环创建进程。

接下来我编写了工具注册表，内容类似这样：

{ "allowed_tools": ["read_file", "search_code", "git_diff", "run_test", "write_file", "apply_patch"], "manual_confirm": ["write_file", "apply_patch"], "denied_tools": ["delete_tree", "change_permissions", "install_package", "push_remote"], "work_directory": "/project" }

这个注册表的意思是：Agent 可以读取项目文件、搜索代码、看差异、跑测试；如果需要写文件，必须弹窗等用户确认；删除操作、权限修改、装包、推远端全部默认拒绝。注意最后一条 work_directory，这是执行层用来判断路径合法性的锚点，所有文件操作都会被先规范化为绝对路径，再检查是否落在这个目录下。

4.4 真实业务场景下的表现与拦截记录

搭好之后，我让它跑了一个真实任务：自动调查一个前端项目为什么构建失败。Agent 的表现是：先读了 package 文件，再看了最近的改动，然后执行构建，得到报错后定位到一个配置文件，并尝试用 apply_patch 修复。

这里就发生了权限拦截：它打算修改的这个配置文件在另一个子目录，虽然还在 /project 下，但因为涉及“写文件”，工具注册表要求进入人工确认模式。我确认了补丁内容后放行，然后 Agent 重新构建，构建通过，整个流程花了大约 7 分钟。

整个过程都写进了审计日志。事后我回看，发现 Agent 在尝试修复时还提出过“直接升级依赖包版本”的方案。由于这个动作不在 allowed_tools 里，执行层直接没有把“install_package”转发出去，Agent 就自动转向了另一种低风险解。这正是权限防线最实在的收获：不是阻止 Agent 解决问题，而是让它回到低成本、低风险的通路上来。

5. 典型问题排查与调优参考

5.1 部署运行中的问题速查表

5.2 三个最典型的坑

第一个坑是只算权重，不算 KV Cache。很多人盯着 70GB 权重量，觉得 128GB 内存肯定够，结果把上下文开到 32K，没跑几轮就 OOM。模型能跑多长上下文，是“内存总量减去权重体积”之后才说得准的。

第二个坑是给 Agent 权限时只看 API，不看工具调用。最初我给 Agent 的“工具”接口倒是做了鉴权，可它执行命令时还是直接调用了宿主机的 shell，结果就等于绕过了全部防线。记住，Agent 使用的每一个执行通道都要单独设防，不能让 shell 成为绕过现有权限体系的侧门。

第三个坑是让 Agent 直接使用高权限命令。不是只有 sudo 才危险，像 rm、mv、chmod 这类命令，一旦被 Agent 在错误路径上执行，后果都是灾难性的。保险起见，把高危险命令直接放进 denied_tools，或者只允许通过专属工具函数来操作文件，不给 Agent 任意命令入口。

5.3 一组可复用的调优参考值

以下是我在实际运行中确认比较稳妥的一组起步值：

• 温度：0.2
• top_p：0.8
• 上下文窗口：默认 16K，内存紧张时降到 4K
• GPU 层数：先按显存上限试探，再逐步降低，直到不发生 OOM
• 批量大小：取 256~512，过高易爆显存
• 工具超时：单次工具调用 60 秒
• 熔断阈值：连续失败 5 次或连续修改文件 10 个时自动挂起

这些值不是铁律，但它足够作为你第一版基线。调的时候每次只动一个参数，不要同时调一堆，否则出了问题很难定位原因。

最后再说一点我自己的体会。端侧推理的价值，不是把 PC 武装成一台小号超算，而是把模型和你的数据放进同一个可信边界里。模型住在本机，数据不出门，Agent 又能帮你在真实环境里动手做事——这三件事凑在一起，才让“带权限的本地编码智能体”从概念变成了可运行的工具。

我踩过几次坑之后最深的感受是：安全防线一定不要等模型跑起来再补，而是要在设计工具调用的第一天就一起写进去。137B 模型再大，也只是个没有手脚的决策器，真正把手伸进你系统的，是四周那些执行通道。把这些通道管好，比把模型塞进电脑更值得你花时间。

未来如果再多说一个方向，我会把精力放在“权限策略自动生成”上：根据项目类型、依赖关系和历史操作，自动生成每个 Agent 的最小权限集。这个能力比单纯追求模型跑多大的算力更有长期价值。