企业官网建设流程全解析

1. 代理编码为什么突然成了基础设施话题

1.1 从“补全一行”到“接手一个任务”的转变

过去两年，大家谈 AI 写代码，聊的都是补全。你敲一个函数名，它帮你把剩下三行补完；你写个注释，它给你生成一段样板代码。这个阶段的工具本质上是“高级自动补全”，人还是绝对主体，AI 只是加速器。

但 2026 年初这一波明显不一样了。代理编码（Agentic Coding）的核心变化在于：AI 不再只响应你当前光标位置的那几行，而是能接受一个相对完整的目标，自己拆解步骤、自己调用工具、自己验证结果、自己迭代修改。你给它的不再是“帮我写个排序函数”，而是“把这个模块的日志格式统一成结构化输出，顺便把相关的单元测试补上”。

这个转变带来的直接后果是：单次请求消耗的算力、上下文长度、工具调用次数，全部呈指数级上升。以前一次补全可能几百 token 就结束了，现在一个代理任务跑下来，几十万 token 的上下文、几十次工具调用、多轮自我修正，都是家常便饭。这就把问题从“模型好不好用”直接推到了“基础设施扛不扛得住”。

我自己的体感是，2025 年下半年开始，身边做 AI 工具链的朋友聊天的重心明显从“哪个模型写代码强”变成了“怎么把代理编码的延迟压下来”“怎么控制单任务成本”“怎么保证并发上来之后不崩”。这就是标题里“AI Infra”这个词被反复提及的根本原因——代理编码正在从玩具变成生产工具，而生产工具需要基础设施。

1.2 企业级平台化到底在解决什么问题

个人开发者用代理编码，痛点其实还好：慢一点就慢一点，贵一点就少跑几次。但企业场景完全不是这个逻辑。

企业级平台化要解决的核心问题，我归纳下来是三个层面。第一层是成本可控。一个中型研发团队，如果每人每天跑几十个代理任务，每个任务消耗的 token 量和工具调用次数如果不加管控，月底账单能吓死人。平台需要做到按项目、按人、按任务类型做配额和计量，而不是让每个人自己去刷 API。

第二层是安全与合规。代理编码意味着 AI 要读你的代码库、要执行命令、要访问内部文档。哪些代码库能碰、哪些不能碰、执行命令的沙箱边界在哪、产出的代码要不要过审，这些在个人场景可以睁一只眼闭一只眼，在企业场景全是红线。平台化本质上是在代理和真实生产环境之间加了一层可控的隔离带。

第三层是效果可复现。同一个任务，今天跑和明天跑结果不一样，A 同学跑和 B 同学跑结果不一样，这在企业里是不可接受的。平台需要把模型版本、提示词模板、工具配置、上下文注入策略全部固化下来，让代理编码从“手工艺”变成“流水线”。

这三层需求叠加在一起，就解释了为什么 2026 年初这个时间点，“企业级平台化”会和“代理编码激增”绑在一起成为热搜话题。不是大家想搞平台，是被逼的。

1.3 这一波热搜词背后的真实信号

把 Claude Opus 4.6、GPT-5.3-Codex 这些模型代号和“代理编码”“企业级平台化”放在一起看，信号其实很清楚：模型能力的竞争已经进入了一个新阶段，单点跑分的意义在下降，能不能撑住代理场景下的长上下文、多轮工具调用、高并发，成了新的分水岭。

我注意到一个细节，这波讨论里很少有人再单纯比“HumanEval 多少分”“SWE-bench 多少分”，大家更关心的是：在真实代理任务里，模型能不能稳定地调用工具、能不能在几十轮交互后还不跑偏、能不能在长上下文里准确检索到关键信息。这些能力，跑分跑不出来，只有真正搭过 infra 的人才知道坑在哪。

所以这篇东西，我不打算写成新闻汇总，而是想从一个实际搭过代理编码平台的人的角度，把这一波变化背后的技术逻辑、实操要点、踩过的坑，尽量讲透。不管你是刚开始接触代理编码的个人开发者，还是正在被老板要求“搞个企业级 AI 编码平台”的工程师，应该都能从里面找到点有用的东西。

2. 代理编码的核心技术点拆解

2.1 代理循环：从单次推理到多轮决策

代理编码和普通代码生成最本质的区别，在于它有一个代理循环（Agent Loop）。普通生成是“输入提示词，输出代码，结束”。代理循环是“输入目标，模型决定下一步动作，执行动作，观察结果，再决定下一步，直到目标达成或达到终止条件”。

这个循环听起来简单，但工程上要处理的问题非常多。首先是终止条件的设计。模型自己说“我完成了”不算数，得有客观验证。常见做法是跑测试、跑 lint、跑类型检查，全过了才算完成。但这里有个坑：如果测试本身写错了，模型可能会去改测试而不是改代码，所以测试文件的修改权限要单独管控。

其次是循环次数上限。不设上限，模型可能在一个死胡同里反复横跳，烧钱烧到天亮。设得太低，复杂任务又做不完。我的经验是，简单任务 10 到 15 轮，中等任务 30 到 50 轮，复杂重构任务可以放到 100 轮以上，但必须配合成本熔断——单任务 token 消耗超过阈值就强制终止并告警。

第三是中间状态的持久化。代理跑到一半挂了，能不能从断点恢复？这在企业场景是刚需。我们当时的做法是每一步动作和观察结果都落盘，恢复时把历史轨迹重新注入上下文。这里要注意，历史轨迹不能无限增长，得做摘要压缩，否则上下文窗口很快就爆了。

2.2 工具调用：代理的手和脚

代理编码的能力边界，很大程度上取决于它能调用哪些工具。最基础的是文件读写、命令执行、代码搜索这三样。但真正拉开差距的是工具的设计粒度。

我见过两种极端。一种是工具给得特别粗，比如只有一个“执行 shell 命令”，模型得自己拼命令、自己解析输出。这种灵活但极不稳定，模型经常拼出危险命令或者解析错输出。另一种是工具给得特别细，读文件、写文件、列目录、搜内容、跑测试、跑 lint 各是一个工具。这种稳定但模型选择成本高，而且工具太多容易选错。

我的建议是按任务类型分层设计。通用层保留文件读写、命令执行、代码搜索三个基础工具；领域层针对具体场景加专用工具，比如“运行指定测试用例”“查询接口定义”“生成数据库迁移脚本”。专用工具的好处是把领域知识固化进去，减少模型自由发挥的空间，稳定性和可复现性都会好很多。

还有一个容易被忽略的点：工具返回结果的格式。返回纯文本，模型解析起来容易出错；返回结构化 JSON，模型理解得更准，但 token 消耗更大。我们实测下来，对于文件内容这类长文本，返回带行号的纯文本性价比最高；对于命令执行结果，返回退出码加截断后的输出，比返回完整输出更实用。

2.3 上下文管理：代理编码最容易被低估的环节

代理编码跑不长、跑不稳，十有八九是上下文管理没做好。一个代理任务跑下来，上下文里会堆积：系统提示词、任务描述、代码库检索结果、历史动作和观察、当前文件内容、错误信息……这些东西如果不加管理，很快就会把上下文窗口撑爆，而且模型在超长上下文里的注意力会严重稀释，关键信息找不着，无关信息一大堆。

我们的做法是分层上下文。第一层是常驻层，放系统提示词、任务目标、关键约束，这部分永远保留。第二层是工作层，放当前正在处理的文件内容、最近几轮的动作和观察，这部分滚动更新。第三层是检索层，放按需检索出来的代码片段和文档，用完就丢。

这里的关键是检索策略。代理编码场景下，最有效的检索不是语义相似度，而是基于代码结构的检索。比如模型要改一个函数，你得把调用这个函数的地方、这个函数依赖的类型定义、相关的测试用例一起检索出来。纯向量检索经常漏掉这些结构关联，导致模型改完这里崩那里。我们后来是向量检索加 AST 分析结合，效果明显好很多。

2.4 模型选型：不是越强越好

Claude Opus 4.6 和 GPT-5.3-Codex 这类模型，能力确实强，但企业场景下不是所有任务都值得上最强模型。我们的策略是按任务复杂度分级路由。

简单任务，比如格式化代码、补全注释、生成样板，用轻量模型就够了，成本可能只有最强模型的十分之一。中等任务，比如实现一个独立函数、修一个明确的 bug，用中档模型。复杂任务，比如跨模块重构、设计新功能、排查疑难问题，才上最强模型。

这个分级路由的收益非常明显。我们统计过，实际任务分布里，简单任务占六成以上，中等任务三成，复杂任务不到一成。如果全部用最强模型，成本要翻好几倍，但效果提升微乎其微。分级之后，成本降下来了，复杂任务的效果也没受影响。

当然，分级路由的前提是任务复杂度可判断。我们的做法是先用一个轻量分类器做初判，再结合代码变更范围、涉及文件数、历史相似任务的成功率做修正。这个分类器不需要多准，大方向对就行，因为路由错了也就是多花点钱或者效果差一点，不会出安全事故。

2.5 沙箱与权限：企业场景的生命线

代理编码在企业里落地，沙箱和权限是绕不过去的。代理要执行命令，但你不能让它随便执行；代理要读代码，但你不能让它读到不该读的仓库；代理要写文件，但你不能让它直接写到生产分支。

我们的沙箱设计是三层隔离。第一层是文件系统隔离，代理只能看到分配给它的工作目录，其他路径一律不可见。第二层是网络隔离，代理默认不能访问外网，需要访问内部服务时走白名单。第三层是命令白名单，危险命令直接拦截，可疑命令需要人工确认。

权限方面，核心原则是最小必要。代理任务创建时，明确声明需要哪些仓库的读权限、哪些仓库的写权限、能不能执行命令、能不能访问网络。平台按声明授权，超出范围直接拒绝。这个声明可以由人写，也可以由模型根据任务描述生成，但必须经过人工确认才能生效。

这里有个实操心得：权限声明要尽量细，但确认流程要尽量简。太粗的权限声明等于没声明，但确认流程太繁琐，大家就会想办法绕过。我们的做法是提供常用权限模板，比如“只读分析”“单仓库修改”“多仓库重构”，选模板一键授权，特殊情况才走自定义流程。

3. 企业级平台化的落地路径

3.1 从单点工具到平台：演进路线怎么走

很多团队一上来就想搭个大而全的平台，结果半年过去还在画架构图。我的建议是分三步走，每步都有可交付的价值。

第一步，统一入口。先把团队里散落的各种 AI 编码工具收拢到一个入口，不管是 IDE 插件、命令行工具还是网页端，背后走同一套 API 网关。这一步的价值是拿到统一的使用数据和成本数据，知道钱花在哪、谁在用、用得多不多。没有这一步，后面所有优化都是拍脑袋。

第二步，统一管控。在入口基础上加配额、加权限、加审计。这一步的价值是让 AI 编码从“个人行为”变成“团队行为”，成本可控、风险可控。很多团队卡在这一步，因为管控意味着限制，大家会有抵触。我的经验是，管控要渐进，先做可见性（让大家看到自己用了多少），再做配额（超了要申请），最后才做硬限制。

第三步，统一能力。把提示词模板、工具配置、检索策略、模型路由这些能力沉淀到平台，让每个人都能用上团队积累的最佳实践。这一步的价值是效果可复现，新人进来不用从零摸索，直接站在团队肩膀上。

这三步不是严格串行的，可以并行推进，但顺序不能乱。先做能力后做管控，大概率会失控；先做管控后做入口，大概率会推不动。

3.2 计量与配额：怎么让成本不失控

代理编码的成本结构比普通 API 调用复杂得多。一次任务可能涉及多次模型调用、多次工具调用、多次检索，每一项都有成本。如果只按 token 计量，会漏掉工具调用和检索的开销；如果只按任务计量，又太粗，没法优化。

我们的做法是多维计量，统一折算。模型调用按 token 算，工具调用按次数算，检索按数据量算，最后统一折算成一个“任务成本分”。这个成本分对用户可见，让大家有感知。配额也是按成本分分配，而不是按任务数或 token 数。

这里有个细节：成本分要定期校准。模型价格会变，工具开销会变，检索成本会变，折算系数不校准，很快就会失真。我们是一个季度校准一次，校准依据是实际账单。

还有一个实操技巧：给成本分加个“预算预警”。比如一个任务预估成本分是 100，跑到 80 的时候给用户发个提示，问要不要继续。这个提示看起来烦，但能有效避免“跑飞了才发现”的情况。我们上线这个功能之后，单任务平均成本降了差不多两成。

3.3 审计与追溯：出了问题怎么查

代理编码在企业里最怕的不是慢，不是贵，是出了事说不清。代码改错了，是谁让改的？代理为什么这么改？中间读了哪些文件、执行了哪些命令？这些如果查不到，平台就没法在企业里立足。

我们的审计设计是全链路记录。任务创建时记录发起人、任务描述、权限声明；执行过程中记录每一步动作、观察结果、模型输出；任务结束时记录最终产出、验证结果、成本分。这些记录按任务 ID 关联，支持按人、按仓库、按时间检索。

记录的量很大，全存不现实。我们的策略是热数据全存，冷数据摘要存。最近一个月的任务全量存，方便排查；一个月以上的只存关键节点和摘要，节省存储。摘要的生成也是用模型做的，把长轨迹压缩成几百字的概述，保留关键决策点。

这里有个坑：审计记录本身也可能泄露敏感信息。代理读过的代码、执行过的命令，都可能包含密钥、内部地址之类的敏感内容。我们的做法是审计记录落盘前过一遍脱敏，密钥、token、内部域名这些模式匹配到就替换掉。脱敏规则要定期更新，因为新的敏感模式会不断出现。

3.4 效果评估：怎么知道平台到底有没有用

平台搭起来了，怎么证明它有用？这个问题不回答，预算就保不住。我们的评估体系分三个维度。

效率维度：任务完成时间、人工介入次数、一次通过率。这些指标反映的是代理编码到底省了多少事。我们统计下来，中等复杂度的任务，用代理编码比纯人工平均快 40% 左右，但复杂任务反而可能更慢，因为代理跑偏了要人工救场。所以效率评估要分任务类型看，不能一概而论。

质量维度：产出代码的缺陷率、回滚率、测试覆盖率变化。这些指标反映的是代理编码有没有引入新问题。我们的数据是，代理产出的代码缺陷率和人工产出基本持平，但测试覆盖率平均高 5 到 10 个百分点，因为代理更愿意写测试。

成本维度：单任务成本分、人均月成本、成本产出比。这些指标反映的是经济性。成本产出比是最难算的，我们的简化算法是“节省的人工时间折算成钱，除以平台成本”，这个比值大于 1 就算划算。目前看，中等任务能到 2 到 3，简单任务能到 5 以上，复杂任务经常小于 1。

这三个维度要一起看，只看一个容易得出错误结论。比如只看效率，可能会觉得复杂任务不值得用代理；但结合质量看，复杂任务虽然慢，但测试覆盖率高，长期维护成本低，可能还是划算的。

4. 实操过程中的关键环节与踩坑记录

4.1 环境搭建：从零到能跑通第一个代理任务

假设你现在要从零搭一个最小可用的代理编码环境，我会这么走。

第一步，选一个代理框架。市面上有现成的开源框架，也有云厂商的托管服务。我的建议是先用开源框架跑通流程，理解代理循环、工具调用、上下文管理这些核心概念，再考虑要不要换托管服务。直接上托管服务，出了问题你都不知道是框架的问题还是模型的问题。

第二步，准备一个隔离的工作环境。最省事的是容器，把代码库挂进去，代理只能在容器里折腾。容器里装好语言运行时、依赖管理工具、测试框架。这里要注意，容器里的代码库最好是克隆出来的副本，不要直接挂载你的工作目录，否则代理改错了你连回滚都麻烦。

第三步，配置基础工具。文件读写、命令执行、代码搜索这三个是必须的。文件读写要注意路径校验，防止代理跑到工作目录外面去。命令执行要设超时，防止代理跑个死循环把容器卡死。代码搜索用 ripgrep 这类工具，比纯文本搜索快很多。

第四步，写系统提示词。这是最容易被低估的一步。系统提示词要明确告诉代理：你的目标是什么、你能用哪些工具、你不能做什么、遇到不确定的情况怎么办、什么时候算完成。我见过太多人系统提示词就写一句“你是一个编程助手”，然后抱怨代理不听话。提示词的质量直接决定代理的表现，值得花时间打磨。

第五步，跑一个最简单的任务。比如“给这个函数补一个单元测试”。观察代理的每一步动作，看它怎么读文件、怎么理解函数、怎么写测试、怎么验证。这一步的目的是建立直觉，知道代理在什么情况下会跑偏。

4.2 提示词工程：代理场景和对话场景完全不是一回事

对话场景的提示词工程，核心是让模型理解意图、生成合适的内容。代理场景的提示词工程，核心是让模型做出正确的决策序列。这两个目标差别很大。

代理提示词里，我认为最重要的三块是：任务边界、工具使用规范、终止条件。

任务边界要写清楚什么该做什么不该做。比如“只修改 src 目录下的文件，不要动 tests 目录”“不要引入新的第三方依赖”“保持现有代码风格”。这些约束不写，代理就会自由发挥，改出一堆你不想要的东西。

工具使用规范要写清楚每个工具什么时候用、怎么用。比如“读文件用 read_file，不要用 cat”“搜索代码用 search_code，不要用 grep”“执行命令前先确认命令是安全的”。这些规范看起来啰嗦，但能大幅降低代理犯低级错误的概率。

终止条件要写清楚什么算完成。比如“所有测试通过”“lint 无错误”“类型检查通过”。终止条件必须是可客观验证的，不能是“代码看起来没问题”这种主观判断。

还有一个技巧：在提示词里放几个正例和反例。比如“好的做法：先读文件再修改；不好的做法：直接覆盖文件”。模型对示例的敏感度远高于对规则描述的敏感度，几个好例子能顶一大段规则。

4.3 工具调用的稳定性优化

工具调用不稳定，是代理编码最常见的故障来源。表现包括：调用了不存在的工具、参数格式错误、该调用的时候不调用、不该调用的时候乱调用。

我们的优化经验是三管齐下。

第一，工具描述要极其明确。工具名、参数名、参数类型、参数含义、返回值格式，全部写清楚。不要用模糊的词，比如“处理文件”这种描述，模型根本不知道是读还是写。参数要加约束，比如路径必须是相对路径、命令必须是白名单内的。

第二，加参数校验和自动修正。模型传错参数是常事，比如该传字符串传了数字、该传数组传了单个值。平台层做一层校验，能自动修正的自动修正，不能修正的返回明确的错误信息让模型重试。我们实测下来，加了这层校验之后，工具调用失败率降了七成以上。

第三，限制单轮工具调用数量。模型有时候会一口气调十几个工具，其中很多是冗余的。限制单轮最多调三到五个，逼模型想清楚再调。这个限制看起来降低了效率，但实际上减少了无效调用，整体效率反而更高。

还有一个细节：工具返回结果要截断。代理读一个大文件，返回几万行，上下文直接爆了。我们的做法是默认只返回前 200 行，需要更多让模型显式请求。命令执行结果同理，只返回最后 100 行加退出码。

4.4 长任务跑飞的排查思路

长任务跑飞，是代理编码最让人头疼的问题。表现是：任务跑了很久，成本很高，但产出完全不能用。排查这类问题，我一般按这个顺序看。

先看上下文长度。如果上下文接近窗口上限，大概率是注意力稀释导致模型迷失了。解决办法是压缩历史轨迹，只保留关键决策点和当前状态。

再看最近几轮的动作。如果模型在反复做同一件事，比如反复读同一个文件、反复跑同一个命令，说明它卡住了。这时候要么人工介入给个提示，要么强制终止重来。

然后看工具调用记录。如果模型在调用一些无关的工具，比如任务明明是改代码，它却在搜文档，说明任务理解偏了。这时候要检查系统提示词和任务描述是不是有歧义。

最后看模型输出。如果模型输出里出现“我不确定”“我需要更多信息”这类表述，说明任务本身描述不清，或者上下文里缺少关键信息。这时候要补充信息重新发起。

我们后来做了一个跑飞预警机制：当任务成本分超过预估值的 1.5 倍，或者连续 5 轮没有实质性进展，就自动暂停并通知发起人。这个机制上线后，跑飞造成的浪费减少了六成以上。

4.5 常见问题速查表

5. 模型能力与基础设施的配合逻辑

5.1 Claude Opus 4.6 这类模型在代理场景下的实际表现

Claude Opus 4.6 这一代模型，在代理编码场景下的提升是实打实的，但提升的点可能和很多人想的不一样。

最大的提升在长上下文里的指令遵循。代理任务跑长了，上下文里堆了几十万 token 的历史，模型还能记住最初的任务目标、还能遵守系统提示词里的约束，这个能力在上一代模型上是明显不足的。我们实测下来，同样一个跨模块重构任务，上一代模型跑到 30 轮左右就开始偏离目标，Opus 4.6 能稳定跑到 60 轮以上。

第二个提升在工具调用的准确性。该调工具的时候调工具，不该调的时候不调，参数格式基本正确，这些看起来是基本功，但实际用起来差别很大。上一代模型经常在该读文件的时候直接瞎猜文件内容，Opus 4.6 这种情况少很多。

第三个提升在自我纠错。跑测试失败了，模型能看懂错误信息，能定位到问题代码，能自己改。这个能力在上一代模型上时有时无，Opus 4.6 上稳定很多。但要注意，自我纠错不是无限的，复杂错误还是需要人工介入。

不过也要说清楚，模型强不等于平台强。我见过太多团队，模型换了最强的，但平台还是老样子，结果代理编码的体验并没有质变。模型能力是上限，平台能力是下限，下限不抬起来，上限再高也发挥不出来。

5.2 GPT-5.3-Codex 的差异化定位

GPT-5.3-Codex 和 Claude Opus 4.6 的定位有明显差异。Codex 系列一直更偏向代码生成和补全的精准度，在代理场景下，它的优势体现在短平快的任务上——生成一个函数、修一个明确的 bug、写一段测试，速度快、准确率高。

但在长任务、多轮交互的场景下，Codex 的表现就不如 Opus 稳定。我们的实测数据是，简单任务 Codex 比 Opus 快 20% 到 30%，成本低 30% 左右；中等任务两者持平；复杂任务 Opus 的成功率明显更高。

所以我们的路由策略是：简单任务优先 Codex，复杂任务优先 Opus，中等任务看历史成功率动态调整。这个策略不是拍脑袋定的，是跑了几个月数据调出来的。模型选型这件事，没有绝对的好坏，只有合不合适。

5.3 模型路由的实操配置

模型路由听起来简单，做起来细节很多。我们的配置大概长这样：

routing: rules: - name: simple_task condition: estimated_complexity: low files_involved: "<= 2" lines_changed: "<= 50" model: gpt-5.3-codex max_rounds: 15 cost_budget: 50 - name: medium_task condition: estimated_complexity: medium files_involved: "<= 10" lines_changed: "<= 500" model: dynamic fallback: claude-opus-4.6 max_rounds: 50 cost_budget: 200 - name: complex_task condition: estimated_complexity: high model: claude-opus-4.6 max_rounds: 120 cost_budget: 800 require_approval: true

这里的关键是动态路由。中等任务先用 Codex 跑，如果连续失败两次，自动切到 Opus 重试。这个策略比静态路由效果好很多，因为任务复杂度的预估不可能百分百准，动态调整能兜住预估错误。

还有一个细节：成本预算要按任务类型设，不能一刀切。简单任务预算给 50 分，复杂任务给 800 分，这个差距是合理的。如果统一给 200 分，简单任务浪费，复杂任务不够用。

5.4 模型版本管理：别让升级变成事故

模型升级是代理编码平台最容易被忽视的风险点。模型厂商发新版本，你跟着升，结果发现行为变了，之前调好的提示词不灵了，之前稳定的任务开始跑飞了。

我们的做法是模型版本锁定加灰度升级。生产环境用的模型版本锁定，不自动升级。新版本先在测试环境跑一批标准任务，对比成功率和成本，确认没有明显退化再灰度到生产。灰度也是分批的，先给 10% 的任务用新版本，观察一周，没问题再扩到 50%，最后全量。

这个流程看起来慢，但比升级出事故再回滚快多了。我们踩过一次坑，某次模型小版本升级，官方说只是修了个小 bug，结果我们这边复杂任务的成功率掉了十几个百分点。后来查出来是新版本在长上下文里的行为有细微变化，导致提示词里的某些约束失效了。从那以后，再小的版本升级我们也走灰度流程。

5.5 多模型并行的成本与收益

有些团队会同时接多个模型，让代理任务在不同模型上并行跑，取最好的结果。这个策略在理论上能提升成功率，但成本也成倍增加。

我们的实测数据是：双模型并行的成功率比单模型高 15% 到 20%，但成本翻倍。对于简单任务，这个投入产出比不划算；对于复杂任务，如果失败一次的代价很高，并行是值得的。

所以我们的策略是复杂任务才开并行，而且并行数量限制在 2 个，不要更多。并行结果的选择也不是简单取第一个成功的，而是让一个轻量模型对比两个结果，选质量更高的。这个对比模型的开销相对很小，但能明显提升最终产出的质量。

6. 代理编码激增对基础设施的真实压力

6.1 并发上来之后，最先崩的是什么

代理编码从个人用变成团队用，并发一上来，最先崩的往往不是模型 API，而是平台自己的中间层。

我们当时遇到的情况是：并发到 50 个任务左右，任务队列开始堆积；到 100 个，上下文管理服务开始超时；到 200 个，审计记录写入把数据库连接池占满了。模型 API 反而还好，因为云厂商的弹性比我们自己的中间层强多了。

所以搭平台的时候，中间层的弹性设计比模型接入重要得多。任务队列要能水平扩展，上下文管理要能分片，审计写入要能异步化。这些如果一开始没设计好，后面补起来很痛苦。

还有一个容易忽略的点：文件系统的 IO。代理任务要频繁读写代码库，并发一上来，磁盘 IO 很容易成为瓶颈。我们的做法是每个任务的工作目录放在独立的高速存储上，任务结束就清理，避免长期占用。

6.2 长上下文带来的存储和检索挑战

代理编码的上下文动辄几十万 token，这些上下文如果全存下来，存储成本很可观。我们的估算是一个中等任务平均产生 20 万 token 的上下文，按团队每天 500 个任务算，一天就是 1 亿 token，一个月 30 亿 token。这些数据全存原始文本，存储成本不低。

我们的策略是分级存储。最近 7 天的上下文全量存，方便排查；7 天到 30 天的存压缩版，用模型摘要成十分之一大小；30 天以上的只存关键节点。这样存储成本能降一个数量级，同时保留了排查问题的能力。

检索方面，长上下文里的关键信息检索是个难题。纯向量检索在长文本上效果会下降，因为向量表示会丢失细节。我们的做法是向量检索加关键词检索混合，向量负责语义匹配，关键词负责精确匹配，两者结果合并排序。这个混合策略在长上下文场景下比纯向量检索效果好很多。

6.3 成本结构的真实拆解

很多人以为代理编码的成本主要是模型调用，其实不是。我们统计过一个中等复杂度的任务，成本结构大概是这样的：

这个结构说明，光优化模型调用是不够的。工具调用、检索、存储加起来占了 45%，这些环节的优化空间很大。我们后来把检索服务从每次全量检索改成增量检索，成本直接降了一半；把审计记录从同步写改成异步批量写，存储成本降了三成。

还有一个反直觉的发现：简单任务的成本占比其实很高。因为简单任务数量多，虽然单任务成本低，但总量大。我们统计下来，简单任务贡献了 40% 的总成本。所以优化简单任务的成本，收益比优化复杂任务更明显。我们的做法是简单任务用更轻量的模型、更短的上下文、更少的工具调用，单任务成本压到复杂任务的十分之一以下。

6.4 稳定性保障：怎么做到 99% 可用

代理编码平台的稳定性，比普通 API 服务的稳定性要求更高。因为代理任务跑一半挂了，不只是请求失败，还可能留下半成品代码、占用中的资源、不一致的状态。

我们的稳定性保障分三层。第一层是任务级重试。任务失败时，先看失败原因，如果是模型超时、工具超时这类瞬时故障，自动重试；如果是代码错误、权限拒绝这类确定性故障，不重试，直接报错。

第二层是状态一致性。每个任务的状态变更都走事务，确保不会出现“任务标记完成但产出没落盘”这种情况。任务的工作目录在任务结束后才清理，清理前先确认产出已经持久化。

第三层是降级预案。模型 API 不可用时，自动切到备用模型；检索服务不可用时，降级到关键词检索；存储服务不可用时，任务暂停而不是失败，等存储恢复后继续。这些降级预案要定期演练，不能只写在文档里。

我们目前的可用性是 99.5% 左右，主要故障来源是模型 API 的偶发超时和存储服务的容量告警。这两个都在持续优化中。

7. 一些实操心得和后续可以做的事

代理编码这件事，我最大的体会是基础设施的成熟度决定了模型能力能发挥出几成。同样的模型，在粗糙的平台上是玩具，在精细的平台上是生产力工具。这个差距不是模型厂商能解决的，得靠做 infra 的人一点点磨。

另一个体会是不要追求一步到位。我见过太多团队想一开始就搭个大而全的平台，结果半年过去还在画架构图。正确的做法是先跑通最小闭环，拿到真实数据，再根据数据决定下一步优化什么。数据会告诉你瓶颈在哪，比拍脑袋靠谱得多。

还有一个容易被忽视的点：代理编码的体验很大程度上取决于失败时的处理。任务成功时大家都开心，但任务失败时，是给一堆看不懂的日志，还是给清晰的失败原因和下一步建议，这个差别很大。我们在失败处理上花了不少功夫，把常见失败原因归类，给出对应的解决建议，用户体验提升很明显。

后续可以做的事，我觉得有几个方向值得探索。一是代理之间的协作，让多个代理分工合作完成复杂任务，比如一个负责分析、一个负责实现、一个负责验证。二是代理能力的持续学习，把成功任务的经验沉淀下来，让后续类似任务跑得更好。三是跨仓库的代理任务，现在大部分代理还是单仓库操作，跨仓库的依赖分析和修改还是个难题。

这些方向都不容易，但值得投入。代理编码这个领域变化太快，今天的最佳实践可能明天就过时了，保持学习和迭代的心态比什么都重要。