四种预设模式（标准/PTC/极简/创造）覆盖了从完整编码Agent到最小复现的不同场景，创造模式还能让Agent自己读开发文档、写代码、跑通并安装插件——当“让Agent给自己造插件”被当作一项卖点时，一个还搞不清Profile和Bundle区别的用户，到底该从哪个模式开始才不至于在“自进化”的叙事里迷失？

一、问题的提出：卖点叙事与用户认知的错位

编码Agent（Coding Agent）指能够自主完成“读需求—检索代码—编辑文件—执行测试—提交变更”闭环的软件系统，其核心区别于代码补全工具的地方在于工具调用与环境反馈。2023年以来，围绕这一形态的工程实践快速成熟，学术界也出现了系统性综述，例如Wang等人在2024年发表的软件工程Agent综述，将现有工作按“感知—规划—行动—记忆”四层进行归类（Wang et al., 2024, arXiv:2308.10620）。本文评述：这类分层框架对理解架构有帮助，但对一线用户最关心的“我该开哪个模式”几乎没有指导意义，因为模式差异并不体现在分层上，而体现在每一层被允许做多深。

四种预设模式的出现，正是把这种“深度”做成了产品开关。标准模式提供完整编码Agent能力；PTC模式（Pre-Trained Connector / Plugin-Tool-Chain，不同产品命名略有差异，本文统一按“受控工具链”理解）在标准能力上叠加外部工具与插件通道；极简模式剥离大部分脚手架，只保留最小可复现的读写执行回路；创造模式则允许Agent读取开发文档、编写插件代码、运行并安装。厂商把最后一项包装成“Agent给自己造插件”，叙事上极具吸引力。

问题在于，卖点描述的是能力上限，用户需要的是能力下限。一个连Profile和Bundle都分不清的用户，如果直接进入创造模式，他面对的不是“自进化”，而是一个自己无法审计的构建系统。软件工程界对“不可审计的自动化”早有教训：2018年发生的left-pad事件虽小，却揭示了深层依赖链的脆弱性；2021年Log4j漏洞（CVE-2021-44228）则证明单个传递依赖可以击穿整个生态。笔者认为，Agent自造插件在机制上与依赖引入同构，风险结构也高度相似，因此选型问题不能只谈“能力有多强”，必须先谈“契约有多清楚”。

核心判断：模式选择的本质不是功能比较，而是信任半径的匹配。你能审计到哪一层，就只应开到哪一层。

二、概念校准：Profile 与 Bundle 到底差在哪

2.1 两个词的定义与常见误用

Profile在Agent语境下通常指能力画像或配置档：它描述“这个Agent被允许做什么”，包括可用工具集、上下文窗口预算、模型温度、权限范围、审批策略等。Profile是声明式的、可读的、通常以配置文件形式存在。Bundle则指打包单元或依赖束：它描述“一组能力如何被封装与分发”，包括代码、元数据、依赖声明、版本约束、安装脚本。Bundle是命令式的、可执行的、需要被安装的。

两者的混淆源于产品界面：很多工具把“选择Profile”和“安装Bundle”放在同一个下拉菜单里，用户看到的是同一个按钮，底层却是两种完全不同的语义。本文评述：这种UI层面的合并是认知负担的主要来源。类比而言，Profile像操作系统的用户权限组，Bundle像软件包管理器的deb/rpm包；改权限组不会改变系统里装了什么，装包也不会自动提升权限，但两者组合起来才决定“谁能运行什么”。

2.2 为什么这个区分决定了选型

如果用户把Bundle当成Profile，就会误以为“装了插件=获得了能力”，从而在权限没有同步收紧的情况下扩大攻击面；如果反过来把Profile当成Bundle，就会误以为“改了配置=换了工具”，在需要新能力时反复调参却始终缺件。笔者认为，四种预设模式的差异，本质上是对Profile与Bundle耦合方式的不同设计：标准模式两者都固定；PTC模式固定Profile、开放Bundle通道；极简模式两者都最小化；创造模式则允许Agent同时修改Profile与Bundle——这正是它风险最高的结构性原因。

这一判断可以得到供应链安全研究的间接支持。OpenSSF在2024年发布的软件供应链安全指南中反复强调“最小权限”与“可追溯构建”两条原则，其逻辑与Agent权限设计同源（OpenSSF, 2024）。本文评述：把Agent的Profile视为权限清单、把Bundle视为构建产物，就能直接复用过去十年在CI/CD与包管理领域积累的治理经验，而不必从零发明一套“Agent治理学”。

三、四种模式的机制拆解与能力契约

3.1 标准模式：完整编码Agent的基线

标准模式提供的是完整闭环：需求解析、仓库检索、多文件编辑、测试执行、差异提交。它的能力契约最清晰——在给定仓库与给定工具集内完成端到端任务。适用场景是有明确验收标准的工程任务，例如修复已知缺陷、补充单元测试、重构局部模块。其失败模式也最可预测：上下文超限导致遗漏、测试覆盖不足导致假阳性通过、对隐式约定的误读。

学术界对这类闭环系统的评测已有较成熟的基准。SWE-bench及其后续版本通过真实GitHub issue构建任务集，要求Agent产出能通过测试的补丁（Jimenez et al., 2024, ICLR）。本文评述：基准分数只能说明“在受控任务分布上的成功率”，不能直接外推到生产环境，因为真实仓库的依赖更脏、测试更慢、约定更隐晦。用户在选择标准模式时，应把基准分数当作上限参考而非预期值。

3.2 PTC模式：受控工具链的扩展

PTC模式在标准模式之上开放了外部工具与插件通道，典型形态包括调用外部API、接入检索服务、挂载专用分析器。它的能力契约是在Profile限定的工具白名单内扩展行动空间。关键设计点在于白名单：哪些工具可被调用、调用参数如何校验、返回结果如何进入上下文。

工具调用并非没有代价。工具描述本身占用上下文，工具返回结果可能引入噪声，工具失败需要重试策略。2024年前后多项研究讨论了工具增强对推理链的干扰，指出工具数量与任务成功率之间存在非单调关系（笔者综合多篇2024—2025年预印本的共识，具体数值因任务而异，此处不引用单一数字）。本文评述：这意味着PTC模式不是“工具越多越好”，而是存在一个与任务复杂度相关的最优工具集规模，超过该规模后，上下文污染与决策延迟会抵消工具带来的收益。

3.3 极简模式：最小可复现回路

极简模式剥离了大部分脚手架，只保留读文件、写文件、执行命令三条基本能力。它的价值不在“弱”，而在可复现与可诊断：当标准模式失败时，极简模式能帮助定位问题究竟出在模型能力、工具设计还是环境配置。这在工程上对应“最小复现用例”（Minimal Reproducible Example）的传统实践。

笔者认为，极简模式被严重低估。多数用户把模式当作“能力档位”，从低到高单向升级，却忽略了极简模式的诊断价值。一个合理的用法是：任何在标准或PTC模式下出现的异常，都先在极简模式下复现一次，确认是Agent问题还是环境问题，再决定是否升级排查。

3.4 创造模式：自举的边界

创造模式允许Agent读取开发文档、编写插件代码、运行测试、安装插件。它的能力契约最模糊，因为Agent既是生产者又是消费者：它写的插件会被它自己加载，形成自举回路。自举在计算机科学中有悠久历史，编译器自举是成熟工程实践，但其前提是存在可信的引导版本与可验证的等价性检查。Agent自造插件目前普遍缺少这两者。

本文评述：把创造模式称为“自进化”是一种叙事夸张。进化隐含适应度函数与选择压力，而当前Agent自造插件的过程没有稳定的适应度度量，也没有跨代选择机制。更准确的描述是“受引导的自举”：人类提供文档与验收标准，Agent完成实现与安装。理解这一点，用户就不会误以为可以放手不管。

四、创造模式的真相：自进化还是自举

4.1 自造插件的技术链路

一条完整的自造插件链路通常包含六个环节：读取开发文档、抽取接口契约、生成插件骨架、实现核心逻辑、本地运行验证、安装并注册。每个环节都有明确的失败点。文档抽取阶段，模型可能误读版本差异；接口契约阶段，可能遗漏必填参数；骨架生成阶段，可能选错模板；实现阶段，可能引入未声明依赖；验证阶段，可能因测试环境与生产环境不一致而假通过；安装阶段，可能覆盖已有插件。

# 自造插件链路的伪代码示意（非真实产品API）
def self_build_plugin(doc_url, target_dir):
    doc = fetch_doc(doc_url)                 # 1. 读取文档
    spec = extract_interface(doc)            # 2. 抽取契约
    skeleton = gen_skeleton(spec)            # 3. 生成骨架
    impl = implement(skeleton, doc)          # 4. 实现逻辑
    ok = run_tests(impl, sandbox=True)       # 5. 沙箱验证
    if not ok:
        return rollback(target_dir)          # 失败即回滚
    return install(impl, target_dir)         # 6. 安装注册

这段伪代码的关键不在实现，而在第5步的沙箱与第6步的回滚。缺少任一环节，自造插件就从“能力扩展”退化为“不可控变更”。笔者认为，用户评估任何宣称支持创造模式的产品时，第一个该问的问题不是“它能造什么插件”，而是“它失败时怎么回滚”。

4.2 供应链视角下的风险结构

Agent自造插件与软件供应链引入依赖在结构上同构：都涉及来源可信性、内容完整性、版本可追溯性、运行时隔离四个维度。差异在于，传统依赖由人类开发者选择，Agent自造插件由模型生成，生成过程本身不可复现（相同提示可能产出不同代码），这使传统的哈希校验与签名机制难以直接套用。

本文评述：可行的缓解思路是把“生成”与“准入”分离。生成阶段允许不确定性，准入阶段必须确定性——即插件在安装前必须通过固定的测试套件与静态检查，测试套件本身由人类维护且版本锁定。这一思路与持续集成中的“质量门禁”一致，并非新发明，但迁移到Agent场景需要额外处理模型输出的非确定性。

五、选型方法论：一条可执行的升级路径

5.1 四步决策法

基于前述分析，笔者提出一条四步决策路径，核心是先建立基线，再逐级扩大信任半径。第一步，用标准模式在目标仓库上跑三类任务（缺陷修复、测试补充、局部重构），记录成功率与失败类型，形成个人基线。第二步，对失败任务用极简模式复现，区分是模型能力问题还是环境配置问题。第三步，仅当确认需要外部工具时启用PTC模式，且工具白名单从最小集合开始，逐个添加并观察边际收益。第四步，仅在具备沙箱、回滚、审计三项能力后，才尝试创造模式，且首个自造插件应选择低风险、易验证的类型。

5.2 三个可操作的检查清单

Profile检查清单：当前Profile允许的工具是否全部必要？上下文预算是否与任务复杂度匹配？权限范围是否超出仓库边界？审批策略是否覆盖写操作？Bundle检查清单：插件来源是否可追溯？依赖是否锁定版本？安装脚本是否在沙箱中执行过？失败回滚是否经过演练？任务检查清单：验收标准是否可自动判定？测试是否覆盖变更路径？变更是否可独立回退？

这三份清单不需要复杂工具，一张表格即可维护。笔者认为，清单的价值在于把隐性判断显性化，让“我觉得可以开创造模式了”变成“三项检查全部通过”。这与航空业检查单、外科手术安全清单的逻辑一致，属于高可靠性组织的通用实践。

拓展阅读：关于最小权限与可追溯构建的通用原则，可参考 OpenSSF 官方站点；关于编码Agent评测基准的细节，可查阅 SWE-bench 项目主页。

六、对比、局限与前沿预判

6.1 四种模式的横向对比

从能力契约清晰度看，标准模式最高，极简模式次之，PTC模式居中，创造模式最低。从审计成本看，顺序恰好相反。从适用人群看，标准模式适合大多数工程任务，极简模式适合排障与教学，PTC模式适合有明确外部依赖的团队，创造模式仅适合具备平台工程能力的组织。本文评述：模式之间不是替代关系而是互补关系，成熟团队往往同时使用多种模式，按任务风险分级调度。

6.2 现有研究的局限

当前关于编码Agent的公开研究，多数聚焦于任务成功率与基准分数，对模式切换的成本与收益缺乏系统测量。少数讨论工具增强的工作也多在受控环境中进行，与生产仓库的差距较大。笔者认为，这一空白短期内难以填补，因为模式设计属于产品细节，厂商缺乏公开数据的动机。用户在实践中应自行积累基线数据，而非依赖通用结论。

6.3 前沿预判

未来一到两年，笔者认为有三个方向值得关注。其一，Profile的形式化：把权限与预算写成可机器校验的规格，而非自然语言描述。其二，Bundle的准入标准化：借鉴包管理生态的签名与审计机制，为Agent插件建立类似仓库。其三，模式间的自动调度：由系统根据任务风险自动选择模式，而非用户手动切换。这三个方向都指向同一目标：把“信任半径”从主观判断变成可度量、可验证的工程对象。

七、结论与展望

回到最初的问题：一个搞不清Profile和Bundle区别的用户，该从哪个模式开始？答案不是某个固定模式，而是一条以标准模式为基线、以极简模式为诊断、以PTC模式为受控扩展、以创造模式为审慎自举的路径。Profile决定允许做什么，Bundle决定装了什么，两者必须同步治理。创造模式的卖点叙事之所以危险，不在于能力本身，而在于它把“自举”包装成“自进化”，让用户误以为可以跳过审计与回滚。

笔者认为，编码Agent的下一阶段竞争，不会停留在“能造多少插件”，而会转向“能否证明每个插件都安全可控”。对用户而言，这意味着选型标准要从功能清单转向治理能力。对研究者而言，这意味着评测基准需要从任务成功率扩展到可审计性与可回滚性。对厂商而言，这意味着把沙箱、回滚、审计做成默认能力，而非高级选项。三者合力，才能让“自举”真正服务于工程，而不是沦为叙事。

八、主要参考文献