企业官网建设流程全解析

Coding Agent 在国内研发团队里已经不算陌生了。我周围不少团队从最初的代码补全，一路用到能自动改 issue、跨文件重构的 Agent 模式，效率提升确实肉眼可见。但伴随而来的是一道绕不开的坎：这些工具默认跑在云端，代码片段、仓库索引、业务逻辑甚至一些内部 API 的设计思路，都会通过接口发到第三方服务去处理。个人开发者可能无所谓，但对要过等保、要过客户审计、或者纯粹对代码资产比较敏感的企业来说，这就是一个必须正面回答的问题。

于是“能不能把 Coding Agent 搬回企业自有基础设施”，从个别技术负责人的私下嘀咕，变成了越来越多团队的正式议题。我自己前前后后经历了调研、PoC、部分落地，再到和基础设施团队一起排障的完整过程，这篇文章就把这套评估框架完整写下来。它不替你做最终决定，但会告诉你该从哪几个维度去算这笔账、PoC 怎么设计才有参考价值、落地时最容易在哪里翻车。

1. 先说清楚：自托管 Coding Agent，到底在托管什么

1.1 云端 Coding Agent 的链路，决定了风险在哪

要评估自托管，首先得搞清楚现在的 Coding Agent 是怎么工作的。以 Cursor 这类偏向智能体的产品为例，你的使用链路大致是三段：

第一段，编辑器本地侧的索引与上下文收集。打开项目后，工具会扫描代码、生成向量索引，并把你正在编辑的文件、相关引用片段收集起来。第二段，推理请求的发起与等待。索引和上下文在本地整理完，真正生成补全、解释、重构建议的部分，必须交由大模型完成。第三段，结果的合入与后续动作。Agent 模式下，模型还能进一步根据你的意图执行命令、修改多个文件。

三段链路里，第二段是核心争议点。因为推理发生在云端，意味着至少有三类数据会跨出企业边界：一是代码仓库的内容，二是包含业务逻辑的上下文片段，三是用户操作行为。这三类数据对很多企业来说都属于需要保护的资产，一旦开发团队使用工具时默认把所有代码都发出去，合规和保密层面就很容易被挑战。

所以“把云端 Coding Agent 搬进企业自有基础设施”，字面上是把第二段（甚至第一段）都收回到内网可控环境里，让代码数据和推理过程不出边界。这个思路本身不复杂，但实际做起来会牵扯出很多问题，这也是需要专门设计评估框架的原因。另外要注意，Coding Agent 这个赛道现在非常拥挤，Cursor、OpenAI 的 Codex、以及一批开源 Agent 框架在能力上互相追赶。对评估团队来说，品牌不是重点，能力边界、数据流向、私有化支持程度才是重点。

1.2 自托管不是二选一，而是几个不同层次

我自己在调研初期犯过一个错误：把“自托管”理解成一个开关——要么全上云，要么全部搬回来。实际接触下来发现，它更像一条光谱，至少有三个层次。

第一层是“模型私有化”。企业自己部署一套开源模型（比如目前很常见的代码类开源模型），所有推理请求都打到内网的模型服务上，编辑器侧仍然用商业工具或开源插件。这一层实现成本相对低，主要解决数据出境问题，但功能完整度取决于插件对私有模型网关的兼容性。

第二层是“工具链私有化”。把补全、Agent 框架、代码索引、RAG 组件这些原本云端的服务，都用开源或可自托管的方案替代部署到内网。这一层体验最接近完整产品，但集成工作量最大，因为要自己拼装。

第三层是“混合模式”。把敏感项目走内网，非敏感项目继续用云端完整产品；或者日常补全走内网轻量模型，复杂任务才放行到云端大模型。对多数中小企业来说，混合模式可能是最务实的一档。我自己见过不少团队，核心产品库和金融类项目严格走内网，前端脚手架、内部小工具就留在云端，两边各取所长，团队抵触情绪也小得多。

关键是要明白，Cursor 这类闭源商业产品的完整功能并不天然支持整体搬走。企业如果要自托管，要么等官方数据驻留类方案，要么在开源生态上搭一套近似方案。评估之前先明确自己要的是哪一层，否则很容易陷入“什么都想要”的被动。

2. 评估必须过的四道关：功能、模型、成本、安全

2.1 功能账：自托管后，Agent 能力会打几折

第一个最容易高估、也最容易在 PoC 期间打脸的，是功能完整度。云端 Coding Agent 体验好，依赖的不只是模型本身，还有一整套配套服务：语义级代码索引、跨文件上下文理解、长期记忆、针对你项目的 RAG 检索、与编辑器/终端的深度集成……这些能力在商业产品里是“开箱即用”的，自托管之后每一项都可能变成你要单独解决的问题。

我在评估时列过一张对比表，核心维度大概是这样：

这张表不是要吓退你，而是提醒团队：自托管大概率不能用“完全复刻云端体验”作为预期。在功能上，更需要做的是给团队划一条“可用下限”，比如代码补全准确率不能低于某条线、Agent 任务完成率不能低于某比例。低于这条线，推广就等于给团队添堵。

2.2 模型账：真正写代码的那颗“大脑”怎么选

自托管意味着模型选择权回到了企业手里，这件事既是机会也是包袱。机会在于，市面上确实已经有几款不错的开源代码模型，支持部署到内网自己掌控；包袱在于，开源模型的综合能力，尤其在极其复杂的跨文件任务上，和顶尖商用模型比通常还有差距。差距并不是不可接受，而是必须在评估初期就形成共识。

模型选型需要先明确用途。如果是 Tab 补全这类高频低延迟场景，一般选择参数量较小的模型，通过量化部署在单张 GPU 上，追求响应速度和稳定性。如果是 Chat 和 Agent 类任务，则需要更大参数的模型，对多卡推理和显存规划的要求都会提高。目前许多团队的实际做法是“大小模型搭配”：小模型负责补全，大模型负责复杂任务。像 DeepSeek Coder、Qwen2.5-Coder 这一批国产开源模型，在代码能力上已经做得相当不错，社区资料也多，很适合作为自托管的第一站。

另外值得关注的是模型的服务化层。自托管推理不能直接拿脚本裸跑，一般要接成熟的推理服务框架，它们负责高并发请求的调度、连续批处理、KV Cache 管理等。再加上一层统一网关，把不同模型统一成 OpenAI 兼容的接口，上层工具接入就会轻松得多。这一步如果没做好，后续接什么工具都会很痛苦。

领域微调是否要做，我的建议是放到第二阶段。自托管初期，先用基础模型跑通流程比追求领域精度更重要。因为代码任务和语言任务不同，项目上下文、文件内容本身携带了大量领域信息，Agent 类工具会把这些信息拼进提示词里。有没有做微调，在端到端体验上的差别，往往不如上下文收集质量来得明显。

2.3 成本账：别只看软件订阅费，人力才是隐藏大头

说到成本，很多人第一反应是“省掉了云端的订阅费”。但实际算下来，自托管的综合成本结构完全不同，至少要考虑四个部分。

一是算力成本。自托管代码模型，最少也得有一张显存足够的 GPU 来部署 7B 到 13B 模型。如果团队规模几十人、并发量不低，或想跑 70B 级别的模型，就要考虑多卡服务器，甚至一个小型推理集群。这块无论自己买还是租，都是一笔持续支出。

二是人力成本。这是最容易低估的。云端产品背后有一个完整团队，厂商替你运维；自托管以后，模型上线、版本迭代、显存监控、故障排查、权限管理，每一项都要有人付出时间。哪怕只是兼职负责，一个月算下来也是非常可观的工作量。

三是集成成本。把身份认证接进现有 SSO、把日志接到统一审计平台、在 CI/CD 里加一道卡点……这些“看起来不大”的接入工作，实际做起来往往比预期耗时。安全团队对新增基础设施的评审、漏洞扫描、上线审批等环节，也可能让时间表拉长。

四是隐性成本。最典型的是 PoC 失败或落地效果不佳后的沉没成本——试过一轮之后发现体验远不如云端，团队反而对 AI 工具失去信心，这种损失比钱更难挽回。

所以我的个人经验是：成本评估不要只算“软件费 vs 硬件费”，而要把人力工时折算进去，按一年维度看总拥有成本。很多团队算完之后发现，20 人以内的小团队自托管在财务上并不划算，真正适合自托管的，通常是代码资产敏感度极高、或有明确合规诉求、且团队有一定平台工程能力的组织。

2.4 安全账：数据不出内网，不等于就安全了

自托管的核心动机是安全，但安全这件事要反过来算：边界内移之后，新的风险点在哪里？

第一，模型本身可能成为新的攻击面。内网部署的推理服务如果有未授权访问漏洞，或者没有做好接口鉴权，等于在内部暴露了一个可以查询模型、甚至可能间接读取上下文的服务。这个服务比一般的 Web 服务更值得重视，因为它的输出天然是“看过代码之后”的产物。

第二，模型权重和配置也是资产。企业经过领域微调或基于内部数据做的提示词工程，如果模型文件、向量索引被随意导出，同样会造成信息泄露。模型文件动辄几 GB 到几十 GB，拷贝非常容易，权限管控上很容易成为盲区。

第三，自托管不等于免审计。等保、ISO、客户审计对自托管系统的要求同样存在，日志留存、权限分离、变更审批这些该有的环节一个都不能少。反而因为系统是自己搭的，出了问题安全团队通常会把责任直接落到平台团队头上。

第四，供应链风险。自托管的软件栈来自开源社区，框架版本漏洞、依赖投毒等问题都需要持续跟进。没有人替你做漏洞公告的筛选和修复，这个工作也得纳入评估。

所以，我建议在评估阶段就引入安全团队的早参与。让安全的同事从方案设计期就提出要求，比如强制 SSO、审计日志、模型服务白名单、密钥管理方式等，等 PoC 落地再补往往要返工。

3. 从评估到验证：一套可以照着做的 PoC 流程

3.1 试点选对，评估就成功了一半

光开会讨论不落地，评估没有任何意义。我建议任何团队在做自托管决策前，都先跑一轮为期一至两周的 PoC。PoC 的目标不是证明自托管比云端好，而是验证两件事：一是在你的网络环境和基础设施条件下，自托管方案能不能稳定跑起来；二是团队真实使用后，效率变化是否可用数据说明。

试点团队的选择非常关键。选太激进的团队，他们会因为“新玩具”的热情给出虚高评价；选太保守的团队，又可能因为不愿意改变习惯而给出虚低评价。比较理想的是找一个人数 3 到 8 人、日常开发节奏正常、对 AI 工具既期待又保持审视的小组。项目最好选一个中等规模、有一定代表性的内部库，既不要拿核心业务系统冒险，也不要拿玩具项目测试，否则指标没有说服力。

PoC 开始前，要先把基线数据打出来。比如试点团队当前的平均代码评审耗时、每周提交量、常见任务完成时间等。没有基线，后续拿到的任何“提升倍数”都是不可信的。

3.2 基础设施准备：从显卡到网关的落地配置

PoC 的基础设施不需要一步到位，但有几样东西必须先定下来。这里有个小建议：PoC 阶段不一定非要买硬件，用云上按小时计费的 GPU 实例来跑是常见做法，等验证完再决定是否采购物理机，能省不少试错成本。

模型推理服务是最核心的组件。以 7B 到 13B 参数的开源模型为例，量化后单卡即可运行，显存大致在 16GB 到 24GB 这个区间；如果要跑 70B 级别，即使量化后，也需要至少两张 48GB 或四张 24GB 的显卡组成单节点。选型时不要只看显存，还要看算力规格和显存带宽，代码补全这类流式输出任务，对显存带宽非常敏感。

推理服务框架建议直接选用成熟的推理引擎，它们支持连续批处理，在高并发下能显著提高吞吐。部署时注意 KV Cache 的显存预留，一般要给并发请求预留至少 20% 到 30% 的显存余量，否则请求一多就会 OOM。

统一网关也很重要。内网模型服务建议统一提供 OpenAI 兼容的 API 格式，这样上层无论是 Cursor 类工具的配置接入，还是自研 Agent、开源插件，都可以用同一套接口。网关层同时承担鉴权和限流，也方便后面做多模型路由。

最后是代码索引与上下文服务。如果自托管的 Agent 工具支持语义索引、RAG，需要准备向量数据库和对应的索引服务。这一步工作量不小，PoC 阶段可以先只索引试点项目仓库，不要一上来就全量索引。

3.3 量化指标：效率、质量、体验三个维度对表

PoC 结束，必须用数据说话。我把评估指标分成三组：

效率类：人均每工作日生成代码的接受量、常见开发任务（比如“给某个模块加日志”“修复某个单测失败”）的完成时间、从写代码到提 MR 的平均耗时。

质量类：代码评审中提出的缺陷率、AI 生成代码的返工次数、CI 失败率。这里要特别留意，不要只看“生成量”，生成量高但返工多，反而说明方案不成熟。

体验类：通过匿名问卷收集开发者的主观评分，包括补全准确率、Agent 任务成功率、交互流畅度、是否愿意继续使用。体验类指标虽然主观，但它直接决定推广阶段的生死。

数据对比的对照组，建议同时做两条线：自托管方案的数据，以及当前云端方案或之前不使用 AI 工具时的历史数据。PoC 的周期虽然短，但只要基线打好了，多少能看出趋势。还要注意，PoC 阶段的使用者通常带着新鲜感，容易出现短期效率虚高，所以综合质量类指标比单纯看速度更有意义。

3.4 结果怎么解读：继续、止损还是换方案

PoC 数据出来后，可能会有三种结果：

如果稳定性和体验都能达标，且团队主观意愿强，那可以进入推广和灰度阶段，下一步要补的是权限、审计和生产级基础设施。

如果稳定性能跑通，但体验上总觉得比云端差一截，比如补全响应延迟偏高、Agent 任务成功率不足，那就先别急着全量。可以从硬件、模型、上下文收集质量三个方向逐一优化，再跑一轮小范围验证。很多问题其实是工程配置问题，而不是方向问题。

如果数据不理想且优化空间有限，也要敢于止损。自托管不是目的，让团队高效写好代码才是目的。止损并不丢人，把 PoC 期间的发现沉淀下来，哪怕最终选择“敏感项目用内网轻量方案、其余继续用云端完整产品”的混合模式，也是一次很有价值的评估。

4. 自托管踩坑实录：那些文档里不会写的问题

4.1 补全场景的延迟，比想象的更敏感

自托管后第一个被吐槽的点，几乎都是补全响应慢。云端产品有强大的边缘加速网络，模型推理节点离用户近，首 token 延迟被压得很低。内网自建，网络传输的延迟比云上小，但推理本身的延迟取决于硬件。小模型量化之后，单并发响应尚可，但多人同时使用时，推理框架如果没有开好连续批处理，或显存分配不合理，请求就会排队，延迟一下子好几倍。

解决思路有几条：补全场景优先用小参数量化模型，把首 token 延迟控制在几百毫秒内；并发高的团队要按峰值预估 GPU 数量，不要按平均使用量配；做好模型预热，避免频繁加载。我见过不少团队“败”在延迟上，不是模型不够聪明，而是并发没有扛住。

4.2 内部库和业务逻辑，是自托管 Agent 的天然短板

云端 Coding Agent 之所以好用，是因为它对公开代码、主流框架的理解非常强。但企业内部系统最大的特点恰恰是“不公开”：自己封装的组件、老系统里的隐藏依赖、特殊业务的命名习惯，这些信息在公开语料里根本没有。自托管后模型对这类内部知识的掌握，天然就弱。

举个例子，让模型给一个内部交易模块加日志，如果它没有检索到相关调用链，可能会生成一套完全不符合内部规范的代码，字段命名风格、错误码约定都对不上。补救方法有三个：一是做好上下文收集，让 Agent 能自动把相关模块、调用链、测试用例拼进提示词，这一点对体验的影响远大于换一个更大的模型；二是把 README、设计文档、接口契约等按统一规范沉淀到代码仓库里，让 RAG 检索能命中；三是对高频的内部 API 封装写少量 few-shot 示例，让模型快速学习企业代码风格。

4.3 权限、审计和隔离，必须在 PoC 阶段就设计

自托管系统要接入企业身份体系，这件事千万别放到最后。如果自托管服务没有和现有 SSO 打通，开发者就会用各自的账号、甚至共享一个管理员账号访问服务，审计基本失效，安全团队上线前一定会叫停。

我在项目中踩过的具体问题是：模型服务网关一开始没有做用户级鉴权，只做了内网 IP 白名单。结果一次安全巡检时，被指出“任何一个内网用户都能直接调用模型服务”，虽然不会造成特别大的损失，但整改成本不低。正确做法是，在网关层接入 SSO 并做用户级 Token 映射，模型侧再做一层服务级密钥，形成双重校验。日志方面，至少要把谁在什么时间调用了什么模型、消耗了多少 Token、请求是否合规，记录成结构化日志接入统一审计平台。

4.4 开发者体验的细节，决定推广的生死

技术架构再完美，如果日常使用体验有割裂感，团队就不会长期用。自托管方案在开发者体验上常见三个问题：

首先是工具链割裂。开发者已经习惯了 Cursor 这一代产品的交互，如果自托管方案要换个插件、换个工作流，学习成本就是实打实的阻力。能兼容原有插件生态、或与 VSCode 系工具深度整合的方案，推广阻力会小很多。

其次是模型输出风格不一致。不同模型之间代码风格差异明显，经常出现今天这个大模型给的格式、明天那个小模型给的风格，代码 reviewer 看了头大。建议在网关层固定“不同场景走不同模型”的路由规则，并尽量统一输出格式要求。

第三是内部使用习惯的适配，比如中文界面、快捷键映射、语言偏好等。看似小事，但我在团队里发现，这些细节对开发者的上手速度影响很大。很多团队从云端切到自托管时，忽略了“迁移指引”本身就是一项工作，结果开发者碰到第一个不顺手的点就退回老工具了。

5. 落地之后的运营体会与下一步

5.1 自托管系统需要一套“准生产”运维机制

很多团队把 PoC 跑通就当大功告成，这是我在复盘时最后悔的一点。自托管 Coding Agent 一旦投入日常使用，它就是一个需要持续运维的生产系统，只是它的用户是开发者、而“业务数据”是代码而已。

运维上至少要有四项基础能力：监控，覆盖模型服务请求量、GPU 利用率、显存占用、首 token 延迟、平均解码速度；告警，覆盖服务不可用、显存溢出、延迟超阈值；日志，覆盖请求审计、错误追踪；以及版本管理，模型升级、推理框架升级、配置变更都要有审批和回滚计划。这些工作可以由平台团队的工程师兼职，但必须在制度上明确责任边界，否则出了问题谁都管不上。

5.2 自托管之后，几个值得投入的方向

如果说 PoC 阶段的目标是“有得用”，那么落地后真正值得做的是“用得好”。我目前观察到的几个方向：

第一，多模型路由。内网同时部署多个规格的模型，按任务类型自动调度：小模型处理补全和简单问答，大模型处理复杂 Agent 任务；高峰期可以用轻量模型兜底。网关统一调度，上层应用基本无感。

第二，代码安全审查 Agent。自托管的推理能力完全可以延伸到更广的工程场景，比如对 MR 做敏感信息扫描、检测依赖漏洞、检查配置合规。内部模型跑内部数据，安全性上比外部服务更有优势。

第三，与现有研发流程深度融合。比如把 Coding Agent 接到工单系统、CI 流程中，让它自动做初步代码评审、自动生成变更说明。这一步的价值会远超单纯的编辑器补全。

5.3 最后分享一点个人体会

关于“开发团队该怎么评估”这个问题，我的核心建议是：不要从工具出发评估，要从风险出发评估。如果你的团队对代码资产外发完全没有顾虑，那留在云端产品上明显是效率最优解；只有当“代码数据边界”成为真实约束时，自托管才值得进入候选名单。评估过程里，功能、模型、成本、安全四个维度缺一不可，PoC 数据是对外汇报和内部决策的唯一凭证，千万不要用感觉代替数据。

另外，我还想提醒一件事：技术方案背后其实是组织能力的考验。自托管方案能不能跑得顺，和团队是否有人愿意长期投入、与安全/平台团队关系是否紧密，关系极大。同样的方案在不同团队，结果可能完全相反。所以评估时也要诚实评估自己团队的能力和精力，别让一个好想法死在没人维护的尴尬里。