简介：一次客户端源码意外公开，让业界看清头部编程Agent的工程实现。本文围绕“模型驱动”与“工程约束（约束工程）”两条Code Agent实现路线展开对比，从架构控制权、上下文工程、工具协议、安全权限、成本结构与适用场景等维度拆解核心差异，并给出条件化选型建议与迁移注意事项，帮助读者建立清晰的Agent架构判断框架。
前段时间，业界某头部编程 Agent 产品在客户端打包发布时出现配置失误：构建产物中的 source map 文件（用于把压缩混淆后的代码映射回可读源码）被一并上传到了公开分发渠道。这类映射文件一旦随包发布，意味着数十万行级别的客户端工程代码处于可完整还原的状态，相当于“裸奔”在所有人面前。
面对这场乌龙，看热闹的人关注八卦，而工程视角的关注点完全不同：这是一次难得的机会，可以完整观察一款能力较强的 Code Agent 的客户端到底是怎么实现的。这里需要先澄清一个常见误解：被公开的是客户端（Agent 运行时）代码，并不是其背后基础大模型的权重或训练代码。于是自然有人问：“模型才是核心，客户端有什么可看的？”
答案与近来业界流行的一个新词有关——约束工程（harness engineering，也被直译为“线束工程”）。新词听起来唬人，但大半是对常识的重新包装：与其不断祈求大模型变聪明、别产生幻觉，不如承认模型是一匹能力强劲但不可全信的野马，给它套上缰绳——用工程系统约束行为、划定赛道、控制风险，它才能稳定出活。而缰绳具体长什么样、勒在哪些部位，恰恰写在客户端源码里。
因此本文的对比主线是：实现一个 Code Agent，存在两条典型路线——把智能押在模型侧的“模型驱动路线”，和把确定性押在客户端侧的“工程约束路线”。它们有什么区别、怎么选、迁移要注意什么，下文逐层展开。
路线A：模型驱动路线（Model-first）
核心假设是“智能主要来自模型本身”。客户端只是一个薄壳，职责限于拼接提示词、透传推理请求、渲染返回结果。模型自主决定探索路径——先看哪个文件、执行什么命令、何时停止，客户端尽量不加干预，开放式工具直接交给模型自由使用。这条路线的哲学是：模型越强，Agent 就越强，工程层保持最小。
路线B：工程约束路线（Harness-first，即约束工程路线）
核心假设是“模型是能力强劲但输出不确定的决策单元”，客户端必须是一套完整的工程系统。它包含确定性主循环、严格的工具协议、上下文工程（结构化注入、裁剪、压缩）、分级权限审批、沙箱执行与全链路观测埋点。从公开的客户端源码看，头部编程 Agent 明显选择了这条路线：模型每一轮只做局部决策（选哪个工具、产出什么参数），而循环推进、失败重试、终止条件、上下文裁剪、安全校验全部由工程代码控制。
这两条路线并非对立教派，而是同一目标下的两种投入策略，共同点很多：
差异不在于“要不要模型、要不要工具”，而在于工程层投入多少、控制权放在谁手里。
这是最本质的差异。模型驱动路线把控制流交给模型，客户端被动执行模型发出的指令。风险在于行为不可复现——同一任务跑两次可能走出完全不同的路径，出了问题难以定位、难以回归测试。
工程约束路线则把主循环握在客户端手里，用确定性代码驱动。一个通用的示意结构如下：
// 通用 Agent 主循环示意（伪代码）while (任务未完成 && 轮次 < 上限) {context = 组装上下文(系统提示, 任务描述, 历史消息, 压缩摘要)响应 = 调用模型(context, 工具定义列表)for (调用 : 响应中的工具调用) {权限校验(调用) // 只读放行 / 写入确认 / 执行强校验结果 = 沙箱执行(调用)追加历史(调用, 结果)}if (无工具调用) break // 模型给出最终结论if (上下文超阈值) 压缩历史()}
在这种结构下，模型的自由度被限制在“每一轮选工具、给参数”这个粒度，循环推进、超限保护、上下文压缩全部是确定性逻辑。直接收益是：行为可复现、可观测、可回归测试。
模型驱动路线通常把对话历史线性堆叠，全部塞进上下文窗口，问题有三：长任务很快触顶；无关历史稀释注意力，指令遵循质量下降；token 成本随轮次线性上升。
工程约束路线则把上下文当作需要主动管理的资源：
从公开源码看，头部产品在上下文管理上投入的代码量相当可观，这也印证了约束工程的基本判断：上下文质量在很大程度上决定了 Agent 的能力上限。
模型驱动路线倾向开放式工具，把可执行任意命令的通道交给模型自由探索，灵活但风险敞口大。工程约束路线的工具设计遵循两个原则：
代码修改方式上也有明显分野：整文件重写式编辑容易“顺手改动无关代码”且 token 开销大；diff/patch 式编辑让模型只产出精确的修改片段，既控制成本，又便于人工审查与回滚。
模型驱动路线的安全兜底主要靠使用者人工把关，适合个人信任环境。工程约束路线的安全体系是分层的：
这正是“线束”一词的本意：缰绳不是一根，而是一束，多个约束点协同工作。
模型驱动路线的调试基本靠“看模型说了什么”。工程约束路线配套会话持久化、断点恢复与全链路埋点，失败任务可以定位到具体某一轮的哪一个工具调用出了问题。对团队级落地而言，这不是加分项，而是必需品。
两条路线的成本曲线形状不同：模型驱动路线前期人力投入低，但长任务成本容易失控——上下文线性膨胀、无效探索轮次多；工程约束路线前期需要投入协议设计、权限体系与评估体系建设，但通过提示词缓存命中（把稳定的系统提示与工具定义放在可缓存前缀）、上下文裁剪与按需检索，长期 token 成本的可控性更好。此处为结构性判断，不涉及具体数字，实际成本取决于任务形态与使用强度。
模型驱动路线改造成本低，接入一个新模型服务通常只需调整请求封装；工程约束路线的调整则牵动工具协议、权限规则、上下文策略与评估基线，改造量大，但换来的可维护性也高。
| 对比维度 | 模型驱动路线 | 工程约束路线（约束工程） |
|---|---|---|
| 主循环归属 | 模型侧主导，客户端被动执行 | 客户端确定性代码持有 |
| 上下文管理 | 历史线性堆叠，易触顶 | 结构化注入 + 压缩裁剪 |
| 工具设计 | 开放式工具，自由生成 | 最小化、正交化、参数强校验 |
| 代码编辑方式 | 整段/整文件生成 | diff/patch 精准修改 |
| 安全控制 | 以人工把关为主 | 分级审批 + 沙箱 + 审计留痕 |
| 行为一致性 | 可复现性较低 | 可复现、可回归测试 |
| 前期投入 | 低 | 高 |
| 长任务成本 | 易线性膨胀 | 可控性更好 |
| 典型适用场景 | 原型验证、探索式任务 | 团队工程化、批量自动化、高安全环境 |
再补充一个部署视角：无论选择哪条路线，底层都需要模型推理服务、沙箱运行环境、日志与监控等基础设施。如果团队不想自建这些底层设施，可以评估主流云服务商在相应通用产品类目上的托管能力（例如百度智能云提供的模型推理与云上运行环境类通用服务），把自建精力集中在 Agent 工程层本身。自建还是托管，取决于团队运维能力与数据合规要求，不存在普适答案。
与其问“哪条路线更好”，不如先问四个问题：
一个务实的混合策略也值得考虑：从模型驱动路线起步，快速验证价值；随任务规模增长，逐步沉淀工具协议、权限体系与上下文管理。工程约束不是一次性建成的，而是随痛点逐步勒紧的。
从模型驱动迁移到工程约束路线，需要重点评估以下事项：
回到最初的问题：一次源码公开事件，真正值得看的是某头部编程 Agent 用数十万行客户端代码给出的答案——强 Agent 的能力不只来自模型，更来自围绕模型搭起来的那套“缰绳系统”。模型驱动与工程约束两条路线的差异，本质是控制权与确定性的取舍：前者用最小工程换取最快起步，后者用系统约束换取可复现、可审查与可控成本。选型没有绝对答案，任务边界、安全等级、团队能力与使用量级共同决定路线；而对多数认真做工程化落地的团队而言，演进方向往往是一致的——从“相信模型”走向“约束模型”，让缰绳本身成为产品能力的一部分。