AI 拿走代码之后，人类工程师的价值不在"写得快"，而在"想得清"。但想得清不是一句口号——它意味着一套全新的能力体系、协作方式和评价体系。

一、代码变便宜了，但问题没消失​

2026 年初，Anthropic 发布了一份《Agentic Coding 趋势报告》。其中有一组数据很扎眼：工程师在约 60% 的工作中使用了 AI，但能"完全委托"给 AI 的任务只有 0-20%。

也就是说，AI 确实帮了大忙，但人类并没有因此闲下来。相反，大部分人的感受是：编码快了，但决策没快；产出多了，但判断没少。

这和我在上一篇"深水区"文章里提到的剪刀差是一致的——AI 产出速度越快，审查者越跟不上。只不过那篇文章讲的是流程，这篇要讲的是人。

问题就来了：当编码成本趋近于零，人类工程师的核心价值到底是什么？

答案不是一句"做架构师"就能打发的。因为"架构"这个词太宽了——它可能是技术选型，可能是系统设计，可能是需求理解，可能是团队协调。而真正值钱的那部分，往往不是写文档、画架构图，而是那些 AI 做不了、也学不会的事。

二、什么叫做"编排者"​

2026 年最流行的说法是：工程师从"编码者"变成了"编排者"。但"编排"到底意味着什么具体动作？

如果把 AI Agent 比作一个执行力极强但理解力有限的新员工，编排者要做的事大致可以分成四类：

第一类：定义问题。 这是最值钱的部分。大部分时候，问题不是"怎么实现"，而是"到底要实现什么"。需求文档里的一句话，背后可能是业务目标、技术约束、用户体验、合规要求的交织。AI 可以在"怎么实现"上做到极致，但"实现什么"仍然需要人类来定义。而且这不是写一句需求就够了——你需要拆解到 AI 能理解的粒度，同时保留足够的灵活性让它在实现层面自主决策。

第二类：设定边界。 这不是写一堆规则文档，而是在编码开始前就把约束结构化为可验证的清单。哪些是硬卡点绝对不能碰，哪些是软卡点尽量遵守，哪些是建议可以商量。更重要的是，这些约束需要在编码过程中被自动检查——不是靠人眼看，是靠机器守。这听起来像工程管理，但在 AI 时代，它是核心能力。因为 AI 不会"凭经验知道"哪些规则不能碰——你必须明说。

第三类：判断质量。 代码产出成本下降之后，审查变成了瓶颈。以前一个 PR 花 20 分钟写、10 分钟审，现在 2 分钟写、10 分钟审。审查时间占比从 33% 飙升到 83%。所以编排者需要把审查从"泛泛看"变成"聚焦看"——机器守硬卡点，人看软约束；机器查范围，人判方向。同时还需要建立一套质量判断的直觉：AI 生成的代码看起来没问题，但跑起来对不对？能扛住真实流量吗？出了事好排查吗？

第四类：兜底责任。 这是最容易被忽略、但也最重要的一点。当 AI 写错了代码导致线上故障，谁承担责任？不是 AI，是人类工程师。所以无论 AI 多靠谱，最终兜底的是人。这意味着编排者不能只是"approve 按钮"——你必须理解 AI 做了什么，为什么这么做，出了问题怎么修。这种理解不是读一遍代码就够的，而是需要系统性地把控：架构是否合理、边界是否清晰、异常是否覆盖、回滚是否可行。

三、真正的稀缺资源​

当代码便宜了之后，什么东西变得更贵了？

第一是判断力。 不是判断"这段代码写得好不好"——那是 code review 的活。而是判断"这个方向对不对"。AI 可以在任何方向上快速产出，但方向本身需要人类来选。这需要的不是编程能力，而是业务理解、技术直觉、风险预判。

第二是注意力。 在 AI 时代，人的注意力是唯一的不可扩展资源。一个工程师一天能深度审查的 PR 数量是有限的，能同时编排的 Agent 任务是有上限的。所以编排者的核心能力变成了"把注意力用在刀刃上"——哪些环节必须亲自看，哪些可以交给自动化，哪些可以信任 AI 的判断。

第三是信任关系。 这是最隐形但也最关键的部分。当团队里的工程师开始依赖 AI 产出代码，信任就从一个"人与人"的问题变成了"人与 AI 与 人"的问题。你信任这个 Agent 的编码质量吗？你信任那个工具的检索结果吗？你信任这套护栏的检测能力吗？这些信任不是一天建立起来的，而是通过一次次的产出-审查-反馈循环慢慢积累。而建立信任的过程本身，就是人类工程师最不可替代的价值。

四、新人的路怎么走​

这是 2026 年最焦虑的问题之一：如果 day 1 AI 已经在写代码了，新人该怎么成长？

传统的成长路径很清楚：写简单代码 → 写复杂代码 → 设计系统 → 定战略。这是一条能力逐渐升级的阶梯。但在 AI 时代，第一级阶梯被踩掉了——新人不再需要从零开始写简单代码，因为 AI 写得更快更好。

那新人从哪里起步？

我认为有三条可能的路径：

第一条：从审查开始。 不让新人写代码，让新人审 AI 的代码。一开始审的是简单的功能，慢慢过渡到复杂的逻辑。通过"看-理解-判断-反馈"的循环，培养技术直觉。这条路径的优势是新人一开始接触的就是完整的生产代码，而不是练习项目。风险是如果审查标准不够清晰，新人可能变成"approve 按钮"而没有真正学到东西。

第二条：从定义问题开始。 让新人先学会写需求、拆任务、定约束，然后再让 AI 实现。这条路径训练的是"想得清"的能力——把模糊的业务需求转化为精确的技术规格。这是编排者的核心能力，越早训练越好。

第三条：从调试开始。 不写新代码，而是修 bug。AI 生成的代码出了问题，新人需要理解代码、定位问题、修复验证。这条路径的优势是训练"理解他人代码"的能力——这恰好是传统编程教育中最薄弱的环节。

这三条路径不是互斥的，可以组合使用。关键是：新人需要一个新的成长阶梯，而不是旧的阶梯被砍掉一级。

五、"蒸馏焦虑"怎么解​

有一个词叫"蒸馏焦虑"。员工每写一份 SOP、每教 AI 一个流程，都是在把知识导出到组织资产里。当员工意识到"我说的越多被替代得越快"，关键知识就开始藏匿。

这不是一个技术问题，是一个激励问题。

解法有三个方向：

第一个：重新定义"蒸馏"的价值。 写 SOP 不是把自己教没，是把自己从执行者变成架构师。当你把一个流程教给 AI 之后，你就不需要再做这件事了——你的时间释放出来去做更值钱的事。这个转换需要组织层面的配合：不能让员工"蒸馏"完之后发现"你的工作被 AI 替代了，所以你需要离职"。那样的话没有人会配合。

第二个：共享 AI 红利。 是用 AI 来扩展组织边界、做以前做不了的事，还是用它来收缩团队？这两条路给员工的信号完全相反。前者让员工觉得"AI 是我的工具"，后者让员工觉得"AI 是我的替代者"。

第三个：评价体系跟着变。 口头说"判断比执行值钱"但 KPI 还是产出量，员工不会信。评价体系需要真实反映编排者的价值：问题定义质量、约束完备性、审查有效性、系统稳定性——而不是"写了多少行代码"。

六、三种工作，三种治理​

还有一个容易被忽略的维度：AI Native 不等于全透明加全自动化。创新需要三个条件——持续注意力、愿意显得愚蠢、反共识。这三个条件在全透明的环境下都很难存在。

所以组织治理需要区分三种工作：

执行类工作：全透明加自动化没问题。需求明确、标准清晰、重复性高——这种工作 AI 做得又快又好，人类只需要定义验收标准。

优化类工作：需要结构化但要留批判空间。性能调优、架构改进、流程优化——这种工作需要 AI 提供数据和分析，但判断需要人类来做。治理方式是半透明：过程和结果可见，但允许批判性思考的空间。

创新类工作：需要保护性环境。新技术探索、新业务模式、新架构实验——这种工作需要半私密、不强制广播、允许试错。用同一种治理方式管三类工作，结果是执行高效加创新死亡。

结语​

2026 年，人类工程师不会被 AI 替代——但会被"会用 AI 的人类工程师"替代。

这不是一个威胁，是一个机会。因为"会用 AI"不是指会用工具写代码，而是指会做那些 AI 做不了的事：定义问题、设定边界、判断质量、兜底责任。

这些不是 AI 时代的新能力，是软件工程一直需要但之前被代码产出掩盖了的基本功。当代码便宜了之后，这些基本功的价值才真正显现出来。

所以人类工程师该做什么？做 AI 做不了的事。做那些需要业务理解、技术直觉、风险预判、信任建立的事。做那些出了事需要兜底的事。做那些需要判断力而非执行力的事。

代码是 AI 的事了。但问题是什么、边界在哪里、做得好不好、出了事谁负责——这些还是人类的事。

而且会一直是。

单 Agent + 单 Harness 是物理极限。要解决 Virtuoso 级别的问题，需要多个不同领域的专家团协作寻优。

三条 Scaling Law​

过去两年 AI 的发展可以归结为三条 Scaling Law：

1. 数据/参数 Scaling（系统一）：加大模型、加数据。这条曲线已经进入收益递减区
2. 推理 Scaling（系统二）：加大推理深度，Chain-of-Thought、Tree-of-Thought。仍在快速演进但天花板可见
3. Agent Scaling（自学习环境）：这是当前和未来 2-3 年的核心增长引擎

为什么 Agent Scaling 是核心？ 因为前两条 Scaling Law 是在"提升单个模型的能力"，而 Agent Scaling 是在"构建一个能持续自我学习的环境"。单模型的天花板是硬的，自学习环境的天花板远得多。

为什么卡在 Expert → Virtuoso​

现实中的 Agent 表现：

• Novice → Apprentice：解决简单任务没问题（写个脚本、查个 API）
• Apprentice → Expert：在特定领域能胜任（部署 vLLM 集群、搭建 RAG 系统）
• Expert → Virtuoso： 卡在这里了

为什么？因为 Virtuoso 级别的问题需要跨领域协作：

• 设计一个生产级推理系统，需要懂 GPU 架构、网络拓扑、调度算法、可观测性
• 搭建一个多智能体应用，需要懂 Agent 设计模式、记忆管理、安全治理、成本控制

单 Agent + 单 Harness 是物理极限。 一个 Agent 无法同时是 GPU 专家、网络专家、调度专家、安全专家。

Agent Harness Cluster 三层架构​

Layer 1：Agent Harness Scale-Out​

解决"如何让多个 Agent 协作"的问题。三个子问题：

Agent 拓扑优化：GPTSwarm、MASS、AgentNet、DyLAN 等研究在探索不同的 Agent 连接方式——是全连接？星型？还是动态路由？拓扑结构直接影响信息流动效率和决策质量。

Agent 调度优化：AIOS、MegaAgent、Quine 等在解决"什么时候派哪个 Agent 上场"——不是所有任务都需要所有 Agent 参与，调度决定了资源利用率和响应速度。

Agent 动态生成：AOrchestra、TDAG、EvoAgent、AutoAgents 在解决"遇到新问题时自动创建新 Agent"——不需要预先定义所有 Agent，系统能按需生成。

Multi-Agent Scaling：多个 Agent 协作 + Memory & Skill Scaling + Meta-Harness 调度。

Layer 2：Data Scale-Out​

数据从原始的数仓层 → 语义层 → 本体层（Ontology）。

• 数仓层：结构化数据，Agent 可以查询
• 语义层：业务含义的抽象，Agent 可以理解和推理
• 本体层：跨领域的概念关联，Agent 可以进行跨领域迁移学习

这一步的关键是让数据从"可查询"变成"可推理"。

Layer 3：Agent Harness Runtime​

• 生命周期管理：Agent 的创建、暂停、恢复、销毁
• 资源调度：计算资源、GPU 资源、内存的动态分配
• 可观测性：每个 Agent 的决策链路、工具调用、上下文变更的全链路追踪
• 安全治理：权限控制、沙箱隔离、审计日志

对 FDE 的实战意义​

如果你是一个 FDE，怎么应用 Agent Harness Cluster？

场景：生产级推理系统部署​

传统方式：一个人或一个小团队，从头搭建。需要懂太多东西，容易遗漏关键决策。

Agent Harness Cluster 方式：

─────────────────────────────────────────────┐
│              Meta-Harness                    │
│   目标：部署 70B 模型生产级推理服务           │
│   约束：延迟<50ms, 可用性>99.9%, 成本<X/月    │
└─────────────────┬───────────────────────────
                  │
    ┌─────────────┼─────────────┐
    │             │             │
┌───▼───┐   ┌────▼────  ┌────▼────┐
│GPU    │   │网络     │  │调度     │
│架构师 │   │拓扑专家 │  │优化专家 │
└───┬───┘   └────┬────┘  └────────┘
    │             │             │
    └─────────────┼─────────────┘
                  │
          ┌───────▼───────┐
          │   Reviewer    │
          │  一致性校验    │
          └───────────────┘

每个 Agent 专注自己的领域，Meta-Harness 负责协调和一致性校验。

关键收益​

1. 质量提升：每个领域都有专家负责，不会遗漏关键点
2. 速度提升：并行探索多个方案，而不是串行试错
3. 可复用性：每个 Agent 的 Skill 可以复用到其他项目
4. 可观测性：每个决策都可以追溯，出了问题知道哪个环节有问题

现在的成熟度​

坦诚地说，Agent Harness Cluster 还在早期阶段。开源工具有 GPTSwarm、AutoGen、LangGraph 的 Multi-Agent 模式，但距离生产级还有一段路。

最接近可用的方案：LangGraph 的 Supervisor + Handoff 模式。虽然不是完整的 Cluster 架构，但已经能解决大部分跨领域协作的问题。

这也正是我们的 LangGraph 实战教程覆盖到的——从单 Agent 到多 Agent 协作，是 LangGraph 学习的第六阶段。

总结​

Agent Harness Cluster 不是"多加几个 Agent"，而是一套完整的架构范式：

• 从"单模型"到"多模型协作"
• 从"人工调度"到"自动拓扑优化"
• 从"一次性任务"到"持续自学习"

跨过 Expert → Virtuoso 这道门槛，靠的不是更大的模型，而是更好的架构。

代码写完了只是开始。物理世界的挑战才是真正的试金石。

前言​

2026 年初，飞猪 CTO 线在一场 ATA 分享中抛出了一个判断：AI 已经解决了信息搜索和代码的问题，PMF 已经找到了。但我们认为，更大的机会在于物理世界的真实消费和生活。

这个判断听起来有些激进。但它背后有一组非常扎眼的数据：OpenAI 的周活是 Anthropic 的 30 倍，但 Anthropic 的年收入（600 亿美金）是 OpenAI（250 亿美金）的 2.4 倍。为什么？因为 Anthropic 的用户在做 coding——每次对话消耗 300K 到 1.5M tokens，而普通聊天只有 25-40K tokens。

Agentic Coding 不仅仅是一个工具升级，它是一个商业模式的颠覆者。而它指向的下一个方向——物理世界的真实消费——比 coding 更大，也更难。

一、Agentic Coding 为什么是通向 AGI 的第一道光​

唐杰教授在 2026 年 AGI-Next 前沿峰会上提出了一个精练的三维框架来描述 AI 技术演进的阶段性：

第一条：数据/参数 Scaling（系统一）。 大规模语料加 Transformer 参数堆叠，逼近模式匹配的上限。这是 2020-2024 的主旋律，现在已经进入收益递减区。

第二条：推理 Scaling（系统二）。 通过强化学习、思维链、Test-Time Compute 让模型"想得更深"。这是 2024-2025 的焦点——DeepSeek-R1、o1/o3 系列——仍在快速演进，但可预见天花板。

第三条：自学习环境 Scaling（Agent Scaling）。 让模型与外部世界持续交互、从环境反馈中自我进化。这条路指向的正是 Agent Scaling Law，是当下和未来 2-3 年的核心增长引擎。

杨植麟在 GTC 2026 上用 Kimi K2.5 的实践将第三条路线具象化为三个工程维度的"共振"：Token 效率、长上下文、以及智能体集群。三个维度的乘积效应，构成了 Agent Scaling 的技术注解。

这三条 Scaling Law 是递进关系。第一条已进入收益递减区；第二条仍在快速演进但可预见天花板；第三条——Agent Scaling Law——是当下真正的增长引擎。

而 Agentic Coding 恰好是第三条路线的第一块试验田。代码世界天然适合 Agent：环境确定（编译器告诉你行不行）、反馈即时（测试跑不跑得通）、试错成本低（改完再跑就是了）。一旦 Agent 在代码世界验证了"自主执行 + 环境反馈 + 自我进化"这条链路，它就具备了走向更广阔物理世界的资格。

二、物理世界的问题有多难​

但物理世界比代码世界难得多。

Coding 和数学问题的特点是：Hard to solve，但 Easy to verify。你写一个哈希排序，对不对一眼就能看出来。而且它是一次性的、静态的——答案和 setup 永远不变。

物理世界消费问题的特点是：同样 Hard to solve，但更头疼的是 Hard to verify。我出两个去巴黎七天的行程规划，或者美加墨看世界杯十天的行程，让两个模型各出一个方案——一眼很难看出谁好谁坏。

还有高度时效性。今天搜酒店和明天搜，库存、价格完全不同，天气、打车能不能打到，都是不可控因素。这对 RL training 来说会引入大量噪声。

还有主观性。我推荐两个景点，我推荐两台扫地机器人，每个人的评判角度都不一样。

这就是用 Coding 方法解决真实物理世界消费问题时面临的核心挑战：你不仅需要解决"怎么做"，还需要解决"怎么判断做得好不好"。

飞猪团队在实践中发现了三个架构创新：

Least Squares 模型合并。 现在很多 expert 模型相对于基座的权重更新彼此几乎是 disjoint 的——它们学到了不同的东西。基于这个观察，可以用一种更便宜的合并方式——用激活值信息做加权的最小二乘合并——把多个 expert 的能力拼起来，效果和昂贵的 OPD 蒸馏很接近。

用大模型取代小模型的 Quick Instruction。 以前用户 query 进来，先用小模型做意图识别、实体抽取、分流……维护一堆小模型。新的思路是：直接在 user prompt 后面加上语义 token，one-shot 给出意图、领域、是否需要搜索等信息，大模型一次推理全部搞定。对旅行电商来说，用户的画像和实时行为数据本来就很长，如果有 10 个小模型，Context prefill 10 次，可能 1 秒都出不来。

三层 KV Cache。 同一个 session 内，前两层保持不变，第三层实时更新。这对旅行购物场景的个性化非常关键。

三、Trip-Bench：把真实世界变成可训练的 simulator​

面对物理世界"hard to verify"的难题，飞猪团队给出的解法是 Trip-Bench——一个 Agentic-RL Pipeline for Physical-World Tasks。

Trip-Bench 的核心思路是：把真实 Agent 的历史轨迹"冻结"为离线世界，让 Agent 自博弈来自动撰写评分器，再把这个评分器直接用作 RL 奖励函数。

从真实的线上轨迹出发，把工具调用的输出冻结成一个离线 SQLite 数据库。用 Agent 自博弈来自动写评分器（rubric），让 RL 有一个确定性的、可复现的奖励信号。把物理世界"hard-to-verify"的问题，转化成了程序可执行的 coding 问题。

但 Trip-Bench 目前还是局部的——数据来自单次 API 调用的快照，reward 信号仍然偏稀疏。下一步是 Shopping-Bench，目标是一个可以无限自我对弈的 world simulator：集成全部消费级 API（旅行、购物、地图、娱乐），让模型在更接近真实世界的环境里学习。

Trip-Bench 最有趣的设计是 Agent self-play writes the grader——三个 Agent 自己跟自己玩：一个出题、一个解题、一个是老师，这样循环。当它达到一定的均衡——环境基本固化了，数据基本固化了，评判标准基本固化了——就认为这是最优的。

这个思路的精妙之处在于：它用博弈论的思想解决了"怎么评判一个旅行规划好不好"这个主观问题。不是人写 rubric，而是 Agent 在自博弈中自然涌现出评判标准。这和"铁律"文章中讨论的确定性 vs 概率性问题一脉相承——Trip-Bench 的本质是把物理世界的概率性问题，转化为 coding 的确定性问题。

四、从单域 Expert 到跨域 Virtuoso——Agent Harness Cluster​

Agent Scaling Law 的真正目标是什么？是提升 Agent 集体的智力等级——从单域 Expert 到跨域 Virtuoso。

Google DeepMind 的 Levels of AGI 框架定义了 AI 系统的智力分级。当前前沿系统（Claude Code、Cursor、Devin 等）在代码、写作、数据分析等结构化领域已经到达 Level 3（Expert）——达到第 90 百分位人类专家的水平。但从 Expert 到 Virtuoso（第 99 百分位）的跃迁，面临一个根本性的困难：

Virtuoso 级别的决策，不是单个专家能独立完成的，而是需要多个不同领域专家团的协作寻优。这恰恰是单 Agent 加单 Harness 架构的物理极限。

Agent Harness Cluster 的技术体系包含三个核心层：

Layer 1：Agent Harness Scale-Out。 能力横向扩展层，包含 Multi-Agent Scaling（拓扑优化、调度优化、Agent 动态生成）、Memory & Skill Scaling（经验积累、技能组合、生命周期治理）、Meta-Harness Scaling（架构搜索、工作流自动生成）。

Layer 2：Data Scale-Out。 数据横向扩展层，数仓层到语义层到本体层。Agent 的智力不仅取决于模型能力，还取决于它能获取和理解的数据质量。

Layer 3：Agent Harness Runtime。 运行时支撑层，包含 Agent 生命周期管理、资源调度与隔离、可观测性与安全治理。

Agent 数量的爆发是必然趋势。原因有三：context 隔离需要 Agent 分裂（按 context 边界切，不按问题类型切）；多视角决策寻优需要 Agent 扩增（多个 Agent 独立推理后综合，决策质量显著优于单 Agent 深度思考）；专精避免 tool 过载（单 Agent 持有超过 15 个工具时，调用正确率显著下降）。

五、组织升级——AI Native 新基建与三层治理​

技术层面的升级，最终要落到组织层面。

Yoho.AI 是阿里内部的一个 AI Native 基础设施项目，覆盖需求分析到设计到编码到验证到归档的全链路。它不是又一个 AI IDE 插件，而是一套完整的 AI Native 工作流。

Yoho.AI 的设计哲学是 Harness，而非 Workflow。传统的 AI 编码工具采用 Workflow 思路——固定 A 到 B 到 C 的步骤。但在复杂业务场景中，这种"流水线上的螺丝钉"思路太脆弱了。Yoho 采用 Harness 模型：定义硬性不变量（改了代码就必须编译、编译不过不许安装），在不变量范围内，AI 有完全的战术决策自由。通过 Hook 系统实时感知 AI 行为，违规时硬性拦截。这就像赛车比赛——不规定你怎么开，但必须在赛道里。

C3 不变量守卫系统（Compile-Commit-Check）是这套哲学的具体实现：改源码必须编译通过、进入下一阶段必须满足前置条件、AI 只能访问声明的工作空间、未完成必要阶段不许停止。这些守卫不是"建议"，是"法律"。

在产品、设计、开发、测试四个角色全面面向 AI Native 升级的过程中，每种角色的核心产出都在发生变化：产品从需求文档变成 Agent 自然语言到结构化 Spec 的自动转换；设计从设计稿变成设计稿到代码的 Skill 链路；开发从写代码变成约束环境下的 AI 自主编码；测试从手动验证变成自动化加 AI 标定失败分类。

一个有趣的信号是：已经有公司开始为 AI Agent 卖保险了。AGT-Lab 的行业调研显示，Mount Insure 推出了面向 AI Agent 的保险产品。当有人开始为 Agent 的行为卖保险时，说明这个生态正在从"实验玩具"走向"商业责任"——可靠性已经是可定价的商品。

结语​

Agentic Coding 不仅仅是"让 AI 写代码"。它是 Agent Scaling Law 的第一块试验田，是通向物理世界真实应用的第一道桥。

Token Multiplier 的经济学证明了这条路走得通——coding 的 token 消耗是聊天的 10 倍到 50 倍，商业价值也是 10 倍量级。Trip-Bench 的 simulator 方法证明了物理世界的"hard to verify"可以被转化为 coding 的"easy to verify"。Harness Cluster 证明了从单域 Expert 到跨域 Virtuoso 的路径不是更好的单 Agent，而是多个专精 Agent 的协作寻优。

代码写完了只是开始。物理世界的挑战——hard to verify、高度时效性、强主观性——才是真正的试金石。

而那个在 Trip-Bench 中自博弈涌现评判标准的 Agent，那个在 Harness Cluster 中协作寻优的 Expert 团队，那个在 Yoho.AI 中被不变量约束的自主执行者——它们正在证明一件事：AI 走进物理世界，不是模型变得更聪明，而是系统变得更可靠。

工具用好了，代码还是会乱。纪律不是束缚，是让 AI 从"能干活"变成"干好活"。

前言​

过去几个月，AI 编程工具的普及速度超出了所有人的预期。Claude Code、Cursor、通义灵码、Qoder——每个工具都在承诺同一件事：你描述需求，AI 写代码。这确实是革命性的，但革命之后呢？

大量团队卡在了一个共同的瓶颈上：编码快了，但交付没快多少。AI 两分钟写完一个功能，人类花二十分钟审查。产出速度远超审查速度，代码越堆越多，质量却越来越难保证。

这里有一个容易被忽略的事实：问题不在工具，在纪律。当编码成本趋近于零，没有纪律的团队会被 AI 产出的速度淹死。这篇文章不讲工具怎么用——那些已经有很多人在写了。我想讲的是：工具用好之后，需要补的工程纪律是什么。

一、纪律从思考前置开始​

Karpathy 提过一个概念叫 Think Before Coding。听起来像是废话——写代码之前不都应该先想清楚吗？但在 AI 编程的语境下，这件事比想象中重要得多。

我在一个实际的 Claude Code 工作流中发现，最有价值的配置不是告诉 AI "怎么写代码"，而是四条规则：

第一条：思考前置。 让模型从原始需求、真实目标、客观约束和潜在风险出发进行分析。如果目标不清晰，先停下来讨论。如果路径不是最短、最简单、最稳妥的，直接指出。如果用户把表面症状当成核心问题，继续追问。这一段配置是最值钱的——它把模型从"执行者"提升到"顾问"，避免无脑跑完一个错误的方向。

第二条：Linus 人格。 让模型按 Linus Torvalds 的视角审视代码——简洁、零特殊情况、敢于拒绝烂设计。这是"个性化加强"，把抽象的规则换成一个有审美、敢拒绝的判断者。AI 默认太"礼貌"了，它需要一点"好品味"的锋利感。

第三条：可验证目标。 对应 Goal-Driven Execution。每个任务必须有清晰的验收标准，不是"大概实现了功能"，而是"这个接口在并发 1000 时延迟不超过 50ms，失败率低于 0.1%"。没有可验证目标的任务，AI 会自行定义"完成"——而它的定义往往和人类的不一样。

第四条：工具链集成。 把规则落到工具链的接口，而不是停留在对话里。规则如果不能被机器检查，就等于没写。

这四条规则和我在"深水区"文章里提到的"约束前置"是一脉相承的。只不过那里讲的是流程，这里讲的是每个 AI 交互瞬间的纪律。

Claude Code 和 Codex CLI 最近在 goal 模式上的分歧，恰好说明了思考前置的重要性。Claude Code 用轻量级独立评估器做会话级目标判定，Codex CLI 用 SQLite 状态机做持久化自主执行。两种方式各有优劣，但它们的共同点是：都需要在动手之前明确"目标是什么"。没有目标定义的自主执行，跑得越快偏得越远。

二、把约束变成可执行的规则​

思考前置只是第一步。更深一层的纪律是：把约束变成机器可执行、可验证的规则。

Superpowers 是一个把 AI 编程从"凭感觉"变成"工程化"的典型案例。它的核心做法有三条：

子智能体隔离上下文。 每个任务用独立的子智能体执行，主会话只做"调度"。为什么要这样？因为 AI 编程最容易出的问题是上下文炸裂——一个 session 里塞了太多不相关的信息，模型开始混淆不同任务的约束和状态。子智能体隔离就像给每个任务一个独立的工作台，互不干扰。

TDD 是默认而不是可选。 红-绿-重构成为铁律，杜绝"事后补测试"。在 AI 编程中，测试不仅是质量保证，更是"AI 理解了对不对"的即时反馈。没有测试的 AI 产出，就像没有编译检查的代码——看起来没问题，跑起来全崩溃。

设计、计划、代码三者强一致。 设计文档、实施计划、代码 commit 互相引用、可追溯。这意味着 AI 生成的每一行代码都能回溯到设计文档中的某个需求，每一个 commit 都能关联到计划中的某个任务。不是"写了什么就提交什么"，而是"按计划写、按设计验、按约束审"。

这和"深水区"里"把默契变成规则"的逻辑完全一致。但在 Superpowers 这里，规则不是写在文档里让人看的——它是嵌在工作流里让机器执行的。文档写得再漂亮，执行时没人逐条核对，等于没写。

三、从工具到服务​

如果说 Superpowers 解决的是单任务的纪律问题，那么 QoderWake 解决的是整个 AI 编程生态的系统化问题。

QoderWake 在 QoderCLI 之上做了 9 大工程模块，把一个"命令行工具"升级为一个"AI 数字员工平台"。这不是简单的功能叠加，而是 AI 编程从个人工具走向组织服务的必经之路。

Daemon 与生命周期管理。 把命令行工具升级为系统服务，标准的 PID/Port/Lock 文件加上心跳管理。AI 编程不再是一次性的交互式对话，而是可以 7×24 持续运行的服务。

Waker 数字员工系统。 每位 Waker 有独立的身份卡——PERSONA.md、TOOLS.md、WORK_STYLES.md——定义了它的角色、能力和工作方式。测试员工 Lily 被自动挂载 6 个内置技能：浏览器操作、变更日志管理、竞品分析、PRD 生成、需求池管理、用户反馈分析。这是从"AI 写代码"到"AI 做工作"的质变。

Trigger 触发器子系统。 QoderCLI 等你敲键盘，QoderWake 让 AI 主动响应外部事件。定时任务、IM 消息、工单、Webhook——AI 不再被动等待，而是主动感知和响应。

Memory 运维。 不是日志记录（写完就忘），而是让记忆成为系统自我进化的载体。失败实验的记忆会在未来阻止相似方向的重复探索，成功实验的记忆会鼓励在此基础上的进一步组合。

安全守卫。 工具调用受 Auth、Policy、Sandbox 约束。能读的不让写，能查个人数据的不让查全量数据。即使 AI 输出了危险动作，执行环境也把影响范围限制住。

从工具到服务的跃迁，意味着 AI 编程不再是个人效率问题，而是组织能力和治理问题。

四、流式输出与上下文压缩——来自 Claude Code 内部机制的启示​

理解 AI 编程工具的内部机制，有助于我们更好地使用它。通过分析 Claude Code 的 LLM 日志，可以发现一些非常有价值的工程启示。

工具注册机制。 Claude Code 通过 system prompt 告诉模型有哪些工具可用。这些工具的定义方式——包括工具名称、参数 schema、执行方式——直接影响模型调用的准确率。工具定义不清晰，模型就会"幻觉"出不存在的 API。

上下文压缩与任务连贯性。 随着对话推进，上下文不断增长。Claude Code 的压缩策略不是简单的截断，而是结构化提取——保留语义骨架，摘要压缩核心结论，在紧急情况下截断参考信息但保留约束清单。这个机制告诉我们：上下文管理不是"窗口越大越好"，而是"按需加载、分级压缩"。

流式输出中的并行工具使用。 Claude Code 在流式输出的过程中可以并行地使用多个工具，而不是等一个工具执行完再调下一个。这需要精巧的多指令分割和 JSON 格式完整性保证——在流式输出中完美分割多个指令，保证每个 JSON 结构完整不破裂。

System Prompt 的内容。 Claude Code 的系统提示词包含了角色定义、工具列表、行为约束、安全规则、输出格式等大量信息。这些不是装饰性的——它们直接塑造了模型的每一次输出。理解 system prompt 的内容，就能理解为什么某些配置方式有效、某些无效。

Session 连续性。 Claude Code 如何连续传递会话信息——即使上下文被压缩，关键的任务目标和约束也不会丢失。这是通过外部的状态管理实现的，而不是依赖模型自己的"记忆力"。

这些内部机制揭示了一个事实：AI 编程工具不是魔法，它是一套精密的工程系统。理解它的机制，才能更好地驾驭它。

五、四层 Harness——把概率模型放进生产系统​

写到这一步，你可能已经注意到一个模式：所有这些纪律——思考前置、约束可执行、工具服务化、上下文管理——最终都指向同一个概念：Harness。

Harness 是把概率模型放进生产系统时自然生长出来的工程架构。它始终围绕四件事：

连接。 模型的输入和输出都是 token，但生产环境不止是 token。数据库里有记录，文件系统里有路径，浏览器里有页面状态。连接层解决的是模型如何与其他数字资产、其他 Agent 以及物理环境通讯。Tool Calling、MCP、A2A，本质上都是这种通讯关系的不同协议实现。

编排。 短任务里，模型的一次回答、一次工具调用，和用户期待的结果之间距离很近，编排问题不明显。但让 Agent 修一个复杂 bug，它要读代码、定位问题、修改实现、运行测试、根据失败日志继续修——任务时间线无法只靠模型自己维持。编排层要做的，就是把这部分原本依赖人持续维持的过程控制，外化成系统结构。

效能。 一个足够强的大模型加上一个非常耐心且懂业务的人类，理论上可以解决所有问题。但能量消耗太大了。效能层的核心原则是：用确定性的复用，替代重复的人类劳动和重复的 GPU 推理。上下文管理减少重复解释，Memory/RAG 减少人工找资料，缓存减少重复计算，模型路由减少不必要的大模型调用。能用 CPU 上的确定性执行解决的，就不应该每次都让 GPU 上的大模型重新推理。

安全。 当 Agent 开始自主地处理企业数据、执行代码、调用内部系统时，安全显得更加重要。输入侧防注入，输出侧结构化约束，执行侧权限和沙箱，高风险动作人在回路，全链路审计。安全层解决的问题是：当模型行为不可完全预测时，系统如何保证权限、数据、动作和责任边界仍然是确定的。

四层之间存在天然张力：效能追求复用，安全要求隔离；编排追求自主推进，安全要求关键节点停下来等人确认。好的 Harness 设计不止是让四层各自最优，而是在张力中找到适合具体场景的平衡。

关于"把概率模型放进生产系统"这个话题，我会在另一篇文章中专门展开——从连接的具体实现、安全四层防线的详细设计，到 15 款 Agent 模型的安全实测对比。那篇文章会从更技术化的角度，完整呈现生产级 AI 系统的全貌。

结语​

AI 编程工具的革命性不在于它让编码变快了——而在于它暴露了一个一直被掩盖的事实：软件工程的基本功，之前都是被人兜底兜掉的。

需求模糊，人靠经验补。上下文丢失，人靠记忆补。约束没说清，人靠默契补。代码有 bug，人靠测试补。当 AI 进入流程之后，这些成本全部暴露，而且回不去。

纪律不是束缚，是让 AI 从"能干活"变成"干好活"。思考前置、约束可执行、工具服务化、上下文管理、Harness 四层架构——这些不是 AI 时代的新发明，是软件工程一直需要、但之前被人的灵活性掩盖了的基本功。

AI 把这些基本功显式化了。不是 AI 要求你这么做，是 AI 让你没法再糊弄了。

AI 不是来"加速"传统工作流的，而是来重构它的。Yoho.AI 给出了一个具体答案：用 OpenSpec 规范意图、用 Harness 约束执行、用 Memory 沉淀知识。

问题：为什么 AI 加速了开发，却没有重构组织？​

大多数公司用 AI 的方式是这样的：

• 工程师用 Cursor/Claude Code 写代码 → 快了 2-3 倍
• PM 还是写传统 PRD → 没变
• 设计师还是出 Figma → 没变
• QA 还是写测试用例 → 没变
• 管理层还是看人力排期 → 没变

结果是什么？每个环节都快了，但整体流程没变。 组织还是那个组织，只是每个人手里多了一个 AI 工具。

这就像在马车时代给每匹马装了电动马达——马跑得更快了，但你还是在马车上。

Yoho.AI 做的事情是换车。

新基建三件套​

1. OpenSpec — 意图规范​

传统方式：产品读 PRD，人写设计文档，设计师出原型，开发估工时。每个环节都有大量信息损耗。

Yoho.AI 方式：AI 自动结构化需求，生成 OpenSpec 规范文档。

OpenSpec 不是一份文档，而是一个可执行的意图契约：

• 用户意图被 AI 解析为结构化需求（谁、在什么场景、要达成什么目标、成功标准是什么）
• 自动生成验收标准（Acceptance Criteria），每个标准都是可测试的
• 生成技术方案骨架，标注出不确定性和需要人工确认的部分

核心差异：从"人写文档 → 人读文档"变成"AI 结构化 → 人工确认 → 自动执行"。

2. Harness — 约束执行​

传统方式：AI 补全代码片段，人负责组装、编译、测试、部署。

Yoho.AI 方式：Harness 约束下，AI 自主完成编译 → 安装 → 验证全流程。

Harness 的核心理念是定义硬性不变量，在范围内给 AI 完全自由。具体做法是 C3 不变量守卫系统：

• guard-compile-required：改代码必须编译通过，不能只写不管跑不跑得通
• guard-gate-check：进入下一阶段必须满足前置条件，不允许跳步
• guard-path-boundary：AI 只能访问声明的工作空间，不能越界
• guard-stop：未完成必要阶段不许停止，防止"做了一半就跑"
• guard-evolution：Harness 自我修改每次会话上限 2 次，防止无限漂移

关键洞察：不是给 AI 加更多的"审批节点"（那是 workflow），而是定义不变量（invariants）。不变量守卫的是底线，不变量之内 AI 可以自由发挥。这是 Harness 和 Workflow 的本质区别。

3. Memory — 知识沉淀​

传统方式：知识散落在飞书文档、代码注释、Slack 聊天记录里。新员工入职靠"问人"。

Yoho.AI 方式：所有决策过程、失败经验、成功模式自动沉淀为结构化记忆。

• 每次会话的决策链路自动记录（为什么选 A 不选 B）
• 失败的尝试和修复过程成为知识库（下次不再踩同样的坑）
• 成功模式固化为 Skill（可复用的解决方案模板）

组织升级：四个角色的 AI Native 化​

关键变化：从"人做执行、AI 做辅助"变成"人做决策、AI 做执行"。

为什么大多数公司做不到？​

三个障碍：

1. 惯性思维：PM 不愿意放下写 PRD 的习惯，工程师不愿意放下自己写代码的控制感
2. 信任问题：让 AI 自主执行全流程，需要极大的信任。信任建立在 Harness 的可靠性上
3. 短期 ROI 诱惑：用 AI 加速现有流程，短期收益立竿见影。重构组织，短期看不到收益

Yoho.AI 的做法是渐进式替代：先用 AI 加速每个环节（让大家尝到甜头），然后逐步引入 OpenSpec/Harness/Memory（让 AI 接管更多），最终完成组织升级。

对 FDE 的启示​

作为 AI 前沿部署工程师，你在 AI Native 组织中扮演的角色是什么？

1. Harness 架构师：定义不变量系统，设计安全边界。这是 FDE 的核心能力——把概率模型放进确定系统
2. Memory 工程师：设计知识沉淀系统，让组织的经验成为 AI 可理解的结构化数据
3. 基础设施提供者：搭建支持 AI Native 工作流的技术栈（计算资源、模型路由、可观测性）

一句话总结：AI Native 组织不是"每个人多用 AI"，而是"组织的工作方式从以人为中心变成以 AI 为中心"。

AI Coding 的终局不是 "AI 取代人写代码"，而是 "人做架构师，AI 做执行者"。但要走到这一步，需要补的工程课比想象中多。

前言​

过去半年，AI Coding 工具的普及速度超出了很多人的预期。编码环节的效率提升是肉眼可见的——一个工程师上午 10 点上线一个新功能、中午做 A/B 测试、下午根据数据下线、5 点上线更好的版本。这是过去需要六周才能完成的迭代，现在一天就走完了。

但与此同时，大量团队卡在了一个共同的瓶颈上：编码快了，交付却没快多少。

这篇文章不讲工具怎么用——那些已经有很多人在写了。我想讲的是：工具用好之后，工程体系需要补什么课。

一、省下来的时间去哪了​

编码效率提升 10 倍是不少团队的实际数据。但端到端交付效率往往只有 2 到 3 倍。省下来的时间去哪了？

被审查、对齐、返工吃掉了。

这里有一个容易被忽略的剪刀差：AI 产出速度越快，审查者越跟不上。很多人以为等模型再聪明一点就好了，但方向反了——这不是模型问题，是流程问题。模型越聪明，这个剪刀差越会加剧。更反讽的是，有些团队的测试阶段反而因为 "AI 写得太快、人需要花更多时间理解和确认产物" 而耗时增加了。

比剪刀差更深层的问题是：过去二十年的研发基础设施是给人用的。

一份不完整的需求、一段没注释的代码、一个不一致的 API 接口——这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力和经验悄悄把缺口补上。开个会问一下、走过去问老王、凭经验猜一下、跑去预发环境试一下。这些动作发生得太自然，自然到我们不再把它看作 "工作"。

但它们是工作。它们是人扛在肩上的隐性成本。

当 AI 进入流程之后，这些成本就会暴露，而且回不去。你没法假装不知道系统的问题。就像你没法看完 X 光片假装骨头没问题一样。

所以最大的风险不在代码质量——代码错误反而容易发现和修复。真正致命的是约束没说清。需求模糊、上下文丢失、验收标准缺失，AI 会在这些空白处用训练数据的 "通用模式" 来填充，写出来的代码能跑，但跑的方向完全不对。

二、约束前置：把默契变成规则​

在传统开发里，很多东西靠人和人之间的默契补齐。一句话、一个点头就够了。但在 AI Coding 里，凡是你没有明说的部分，Agent 大概率会自行合理化。

AI 最危险的不是 "不知道"，是 "以为自己知道"。它给出的答案看起来合理，但实际上是用训练数据里的普遍模式填充出来的，不一定符合你的业务场景、工程规范和线上要求。

所以第一课就是：在 AI 动手之前，先把约束说清楚。

具体来说，需求阶段需要多问几个问题。这个功能要解决的根因是什么——去掉它能达成同样目标吗？如果并发量翻十倍、数据量翻一百倍，系统行为会怎样？这里的 "正常处理" 具体指什么，在不同角色看来含义相同吗？攻击者会怎么利用这个功能，运维怎么排查异常？

这些问题看起来像是在找茬，但其实是在强制暴露盲区。这个过程不能交给 AI 自己做——追问必须是交互式的，人必须参与。这是整个约束体系里唯一不能自动化的环节。

到了技术方案阶段，约束需要变成结构化的清单。每条约束应该包含几个要素：具体的描述、约束等级（哪些是硬卡点不能碰、哪些是软卡点尽量遵守、哪些是建议）、怎么验证、在哪个阶段验证、预期结果是什么。

但很多人走到这一步就停下了，觉得写了个清单就完事了。这里有个常见的误区：把 "约束" 等同于 "文档"。约束的核心标准只有一个——能否被机械化地验证。如果不能，就是无效约束。文档写得再漂亮，审查时没人逐条核对，等于没写。

还有一个更细的层次：任务拆解时的约束绑定。不是把整个约束清单丢给 AI，而是为每个编码任务精确匹配相关的约束子集。AI 在写 T3 任务时只需要关注 T3 相关的约束，而不是面对一堆不相关的规则。

三、流程编排：让 AI 按流程走​

AI 编码最危险的不是 "写错"，是 "写偏了"——边写边自由发挥，最后和初衷对不上。

所以需要把流程拆成几个职责分离的阶段，每个阶段强制 AI 切换角色。

第一步是只读不写。让 AI 先读代码库，做架构考古、Git 热点分析、依赖追踪，但不允许写代码。这步的核心是 "先看再想"，而不是 "看了就写"。

第二步是想不做。不写代码，先想清楚有哪些方案可选，对比优缺点。这步很多人会跳过，觉得 "我想好了直接写就行"，但跳过探索的代价往往是写到一半发现方向错了。

第三步是把方案变成可执行的规范文档，包含设计、任务拆解、验收标准。想法到规范的转换，是把模糊的 "我觉得应该这样" 变成精确的 "你需要做这三件事，验收标准是这四个条件"。

第四步才是按规范实施。TDD，反模式检测，严格按规范逐任务落地。

第五步是规范对齐验证——不是泛泛看代码，是逐条核对约束清单是否被遵守。

第六步是安全审查——攻击面、数据流、依赖漏洞扫描。

这套流程的核心价值是职责分离：侦察只读不写，探索只想不做，提案只定方向不写代码。每个阶段切换角色，避免在一个 session 里角色混乱。

但流程不等于仪式。对于熟悉的项目，侦察可以跳过；对于简单需求，探索可以合并到提案。流程的价值在于可裁剪，不在于完整性。我见过不少团队把六步当成必须全跑的 checklist，结果效率反而更差了。

还有一个容易被忽视的环节：编码过程中发现方案需要调整，不是重新跑一遍流程，而是把变更反向同步到方案文档，保持方案和代码一致。没有这一步，流程和实际代码很快会脱节。

四、验收：从希望遵守到验证遵守​

传统代码审查有个问题叫 "泛泛看"——reviewer 可能只看了逻辑对不对，没注意到关键约束是否被遵守。产出速度远超审核速度的时候，这套机制就失效了。

所以需要从 "人眼看" 变成 "机器查"。

在技术方案到编码的入口处设一道关：硬卡点为零、约束完备才允许进入编码。在代码审查到发布的入口设第二道关：硬卡点风险为零、约束覆盖率达到要求才允许提交。在发布到线上的入口设第三道关：影响范围可控、风险评级不超过中等才允许上线。

最容易做砸的是变更规模的自适应。一刀切全量检查会扼杀效率，一刀切全部快速通过会扼杀质量。正确做法是多维度判断：代码行数、涉及的资金或状态或安全、变更的文件数、历史 bug 率——综合判断走哪条通道。这不是流程问题，是算法问题。

同时还需要检测一些 AI 特有的缺陷：代码里调用的 API 在项目依赖中是否真的存在（幻觉 API）、实现范围是否超出了任务定义（过度实现）、当前任务绑定的约束是否都被覆盖了（约束遗忘）、代码和设计方案的偏差是否超过阈值（偏差放大）。

这些检查不是要替代人的审查，而是帮人的审查聚焦到真正需要判断的地方。硬卡点机器来守，建议项人来看。

五、上下文管理：不是越多越好​

很多人以为上下文窗口越来越大，问题就解决了。方向反了——窗口越大，AI 越容易迷失重点。

类比操作系统：虚拟内存不是因为物理内存不够才发明的，是因为 "全量加载" 本身就是错的架构选择。上下文窗口也一样——按需加载、分级压缩、不可换出页，这些是架构问题，不是资源问题。

具体来说，上下文应该分三级。第一级是必须传的、不可压缩的：约束清单、硬卡点规则、资金安全规则。第二级是重要的、可以摘要压缩的：技术方案核心章节、代码变更摘要。第三级是参考性的、按需注入的：知识库、历史变更记录。

随着对话推进，上下文会不断增长，需要做三阶段压缩：先结构化提取保留语义骨架，再摘要压缩保留核心结论和数据，紧急情况下截断第三级、进一步精简第二级。但有一个原则——约束清单在任何阶段都不可压缩，它是硬红线。

和上下文管理相关的一个问题是知识防腐烂。

知识库不更新，三个月就废。但防腐烂最难的不在技术，在激励。一个可行的做法是把知识更新和代码变更绑定：PR 改了某个模块，自动触发关联知识的更新提醒，不处理不能合并。把防腐烂从自觉行为变成流程硬约束。

具体可以做三件事：PR 关联复核——修改的文件路径若在某条知识的绑定路径里，评审阶段强制确认知识是否需要更新；定时巡检——定期扫描长尾知识，生成腐烂候选清单；AI 起草加人审签——大部分更新由 Agent 起草，owner 确认，边际成本压到最低。

六、人和组织​

写到这里，技术问题基本讲完了。但还有一个更大的问题不能回避：人怎么办。

有一个词叫 "蒸馏焦虑"。员工每写一份 SOP、每教 AI 一个流程，都是在把知识导出到组织资产里。当员工意识到 "我说的越多被替代得越快"，关键知识开始藏匿——而 AI 友好化恰恰需要员工说出哪些隐性约定需要被结构化。

还有一个叫 "培养断裂"。旧路径很清楚：day 1 写简单代码，几年后写复杂代码，然后设计系统，最后定战略。新路径里这条线断了——day 1 AI 已经在写代码，那 day 1 的人到底应该做什么？

这两个问题叠加起来，会形成一个负反馈环：入门级岗位消失导致资深工程师断层，资深工程师因为蒸馏焦虑藏匿知识导致转型无法推进，评价系统不匹配导致员工没有动力参与转型。

最诚实的做法是承认没有完美方案。但有几个方向能避免最坏的情况发生。

第一，明确 AI 红利的分享方式。是用它来扩展组织边界、做以前做不了的事，还是用它来收缩团队？这两条路给员工的信号完全相反。

第二，把 "蒸馏" 重新定义。写 SOP 不是把自己教没，是把自己从执行者变成架构师。

第三，评价系统必须真实跟着变。口头说 "判断比执行值钱" 但 KPI 还是产出量，员工不会信。

还有一个容易被忽略的维度：AI Native 不等于全透明加全自动化。创新需要三个条件——持续注意力、愿意显得愚蠢、反共识。这三个条件在全透明的环境下都很难存在。

所以组织治理需要区分三种工作：执行类工作全透明加自动化没问题；优化类工作需要结构化但要留批判空间；创新类工作需要保护性环境——半私密、不强制广播、允许试错。用同一种治理方式管三类工作，结果是执行高效加创新死亡。

结语​

AI Coding 的终局不是 "AI 取代人写代码"，而是 "人做架构师，AI 做执行者"。

但要走到这一步，需要补的工程课比想象中多。约束前置、流程编排、验收闭环、上下文管理——这些不是 AI 时代的新发明，是软件工程本该有、但之前被人兜底兜掉了的基本功。

AI 把这些基本功显式化了。不是 AI 要求你这么做，是 AI 让你没法再糊弄了。

10 天 37 组实验的 Agent 依然需要人类的灵感一击——这不是 Agent 的弱点，是人类价值的证明。

前言​

一个推荐系统团队用 9 层 Multi-Agent 架构自主完成了生成式召回模型的研发。10 天，37 组实验，从基线 HitRate@100=0.2038 一路迭代到多路径融合。Agent 自己探索了 MoE 专家数量、层数、门控机制、激活函数、学习率、auxiliary loss 等多个维度，自主尝试、自主记录、自主优化。

但同样值得记录的是系统做不到的事：最关键的一次性能跳跃，来自一个人工输入的创新性 Idea——Target Aware Memory，为码本不同 decode 阶段配置差异化的 memory。回顾前三个阶段，系统自主完成的架构探索本质上都是在已有架构的参数空间内做网格搜索，而 Target Aware Memory 引入了一个全新的机制维度。

这恰好勾勒出当前人机协作的真实边界：Agent 擅长高效试错和知识积累，而真正跳出框架的灵感，仍然属于有想法的人类。

一、Agent 擅长试错，人类负责灵感​

推荐系统召回模型的研发是一个典型的实验密集型工作。一次完整的实验周期包含方向调研、代码实现、配置生成、集群提交、结果分析、知识记录。单次执行需要数小时到一天，且每一步都埋着坑——em_id 和 item_id 混淆导致 hitrate 全零，CAST 用 INT 导致大商品 ID 溢出。这些踩坑经验散落在个人记忆中，换一个人很可能从头再踩一遍。

既然瓶颈在执行而非思考，一个自然的想法是：用 Agent 把执行层整体接管。

但单体 Agent 架构会撞上三堵墙：

上下文的物理天花板。 一次完整实验涉及模型代码、训练 biz 配置、集群日志、ODPS SQL、历史实验记忆等，单一上下文窗口无法容纳所有信息，压缩后又会丢失关键细节。

角色冲突。 写代码时需要关注维度对齐和异常防护的细节，做实验分析时需要高层次的指标对比和方向判断，两种思维模式放在同一个 Agent 中会互相干扰，质量两头打折。

失败耦合。 代码验证失败不应该污染实验提交逻辑，集群任务 OOM 不应该影响代码审查流程。单体架构下，一个环节的异常会连锁污染后续所有环节的上下文。

所以他们选择了分层的 Multi-Agent 架构：四层 Agent，9 个智能体，每个有明确的职责边界、输入输出契约和独立的失败处理策略。L1 知识与记忆层负责信息摄入和记忆管理；L2 任务编排层包含 Planner 有限状态机、Architect 代码生成、Reviewer 质量审查；L3 代码执行层有 Validator 三级门控、Training Biz Creator、Experiment Executor、Task Error Fixer；L4 实验反馈层负责信号回收和知识沉淀。

这套系统在 10 天内完成了 37 组实验的自主迭代。架构探索中大量实验结果为负——16 专家的 MoE 直接下降 19.7%，3 层 MoE 下降 13.0%。但也有正向发现：RMSNorm 带来加 2.7%。超参调优中发现了最优组合加 5.3%。验证环节拦截了约 60% 的模型代码 bug。

但最大的性能跳跃——Target Aware Memory——来自人工。这证明了一件事：Agent 擅长的是在给定方向上高效执行和迭代优化，而真正跳出既有框架的创新性 idea，仍然高度依赖人类研究者的洞察。

这和"2026 年人类工程师"文章里提到的"编排者"角色完全一致。编排者最值钱的工作是定义问题——Agent 可以在"怎么实现"上做到极致，但"实现什么"和"往哪个方向突破"仍然需要人类来定义。

二、从编码者到定义者——新分工​

当 Agent 把执行层接管之后，所有角色都在升级。

Yoho.AI 的实践展示了一个完整的技术创业路径：产品、设计、开发、测试四个角色全面面向 AI Native 进行工作模式升级。

产品角色从写需求文档变成生产 Agent 自然语言到结构化 Spec 的自动转换。在 Aone 提交需求后，Yoho Server 自动触发 AI 流水线：结构化阶段通过 MCP 工具获取工单详情、评论、关联语雀文档；评审阶段用 7 维度雷达图评估需求质量；记忆召回三路并行；最终生成 OpenSpec 格式的技术设计文档。产出物是一份 AI 和人都能理解的、可验证的 spec。

设计角色从出设计稿变成设计稿到代码的 Skill 链路，MCP 对接设计系统。

开发角色从写代码变成 Harness 约束下的 AI 自主编码，C3 不变量保证质量底线。开发者启动 Harness 环境，AI Agent 进入约束执行模式——读取 spec 理解要做什么，召回项目知识，自动完成编码到编译到提交到安装到运行 E2E 测试。整个过程人不需要逐行指导。

测试角色从手动验证变成 dfxcli 加 WDA 自动化，AI 标定失败分类。

从需求到验证通过，核心交互只有两步：确认设计文档加确认测试结果。

AI 时代产品经理的"基本功"也在发生变化。不再是画原型、写 PRD、跟进排期，而是把模糊的业务需求转化为精确的技术规格，把人类的意图翻译成 AI 能理解的结构化规范。这是编排者的核心能力，越早训练越好。

三、用户意图不是状态，是过程​

如果人类工程师的新角色是"定义者"，那他们需要理解一个更根本的问题：用户到底想要什么？

"用户意图"这四个字，可能是互联网产品领域被引用最多、却也被理解得最模糊的概念之一。在搜索引擎中，用户意图约等于查询词背后的真实需求。在推荐系统中，意图进一步泛化为用户行为序列背后的潜在偏好。在电商场景中，意图更常被窄化为"购物意图"。

但现实远比这复杂。一个用户打开淘宝，她的意图可能是"给即将生日的闺蜜挑个礼物，预算两百左右，要有点小心思但不要太正式"——这不是一个品类标签能概括的，它包含了社交关系、预算约束、情感调性、场景适配等多重维度。更重要的是，这个意图本身是流动的。

传统定义建立在三个失灵假设之上：

意图是离散可枚举的。 真实的意图往往是跨品类的（"布置一个温馨的阳台角落"涉及绿植、灯具、坐垫、收纳），甚至是非商品化的（"让自己看起来更有精神"）。

意图是用户主动表达的。 大量用户在消费早期阶段并不明确自己的需求，他们需要被"激发"而非被"匹配"。

意图是稳定的。 一次浏览 session 中用户的意图可能经历多次转变、分裂、甚至完全逆转。

大语言模型的出现改变了这一切——我们现在有了能够理解自然语言语义、追踪长程上下文、进行复杂推理的技术基础。问题不再是"能不能"，而是"要不要"以及"怎么做"。

新的意图引擎把意图定义为一个有生命周期的过程：萌芽、强化、稳定、衰退、消亡。三层意图供给从物理层到需求层再到偏好层，逐层细化。L0 物理层是用户长期稳定的属性；L1 需求层是元意图表达，包含品类、场景、受众及推断理由；L2 偏好层是细化偏好，包含品牌倾向、价格预算、决策状态及实时心理。

一个关键洞察是：对话不等于打字。气泡式追问、选择题而非填空题、从行为序列中推断"用户在犹豫什么"——本质上是系统单方面在做对话推理，用户感知到的只是"推得越来越准"。

四、信任与控制权​

当我们拥有了强大的 AI Agent 能力后，一个根本性的设计哲学分歧浮出水面：我们是在为用户理解意图，还是在让 Agent 替用户决策？

OpenAI 在 ChatGPT 中推出了购物功能和 Agentic Commerce Protocol，与 Stripe 合作建立开放标准。Amazon 的 AI 购物助手 Rufus 据报道已驱动超过 120 亿美元销售额。Agent 替用户决策已经不是设想，而是已发生的事实。

但现实给出了有趣的反馈：OpenAI 后来关闭了 Instant Checkout 功能。原因是，当 Agent 直接替用户完成购买决策时，用户的信任和掌控感是脆弱的。

这恰好印证了两种立场在极端情况下的问题。纯粹的"以人为本"可能导致过度保守——明明系统已经高度确信用户需要什么，却还要反复确认。纯粹的"以 Agent 为本"则可能导致 Filter Bubble 的深化——用户被困在系统认为的"你是谁"的牢笼里。

答案是在不同的决策阶段和确信度下，动态调整人机协作的比例。当系统对意图的判断高度确信时，可以偏向 Agent 主导；当意图模糊或涉及高决策成本时，应该偏向人的主导。

用户对 AI 系统的信任建立在两个基础上：一是系统的能力，二是系统的透明度。缺少透明度的高能力系统反而会引发更强的不信任。真正的以人为本，包含了让人保持知情权和控制权。

这也和"铁律"文章中讨论的安全层是一致的——安全不只是技术问题，也是信任设计问题。

五、新人的阶梯​

这是 2026 年最焦虑的问题之一：如果 day 1 AI 已经在写代码了，新人该怎么成长？

传统的成长路径很清楚：写简单代码，写复杂代码，设计系统，定战略。但在 AI 时代，第一级阶梯被踩掉了。

那新人从哪里起步？

第一条：从审查开始。 不让新人写代码，让新人审 AI 的代码。通过"看-理解-判断-反馈"的循环，培养技术直觉。优势是新人一开始接触的就是完整的生产代码。风险是如果审查标准不够清晰，新人可能变成 approve 按钮而没有真正学到东西。

第二条：从定义问题开始。 让新人先学会写需求、拆任务、定约束，然后再让 AI 实现。训练的是"想得清"的能力——把模糊的业务需求转化为精确的技术规格。这是编排者的核心能力，越早训练越好。

第三条：从调试开始。 不写新代码，而是修 bug。AI 生成的代码出了问题，新人需要理解代码、定位问题、修复验证。训练"理解他人代码"的能力——这恰好是传统编程教育中最薄弱的环节。

这三条路径不是互斥的，可以组合使用。关键是：新人需要一个新的成长阶梯，而不是旧的阶梯被砍掉一级。

10 天 37 组实验的 Agent 案例为这三条路径提供了一个生动的注脚：Agent 完成了执行层的所有工作（写代码、配环境、跑实验、分析结果），但人类研究者依然在定义问题（决定探索哪个方向）、审查结果（判断实验是否有效）、调试异常（当集群任务 OOM 时介入）。新人的成长路径，恰恰就是在这三个维度上逐渐升级——从"能看懂 Agent 做了什么"到"能判断 Agent 做得好不好"到"能告诉 Agent 该做什么"。

结语​

AI 把活干了——执行层的活。代码实现、配置生成、集群提交、结果分析，这些工作 Agent 确实干得又快又好。

但人类工程师该做什么？做 Agent 做不了的事。做那些需要创新性 idea 的事。做那些需要把模糊的业务需求转化为精确技术规格的事。做那些需要理解用户真实意图的事。做那些需要在 Agent 出错时兜底的事。做那些需要判断方向对不对的事。

那个让推荐模型性能实现最大跳跃的 Target Aware Memory，不是 Agent 自己探索出来的，是人类研究者灵光一现的 idea。但这不意味着 Agent 白干了——恰恰是 Agent 在 37 组实验中积累的知识和记忆，为这个 idea 提供了验证和落地的土壤。

Agent 做执行，人类做定义。Agent 负责试错，人类负责灵感。这不是人类价值的削弱，是人类价值的重新聚焦。

代码是 Agent 的事了。但往哪个方向走、走得对不对、出了事谁负责、用户真正想要什么——这些还是人类的事。

通过完整记录一次 Claude Code 任务的 LLM 日志，我们看到了它告诉模型有哪些工具、如何处理上下文压缩、如何并行执行工具、以及如何保证多指令的 JSON 完整性。

背景​

Claude Code 是一个黑盒产品。你输入指令，它输出代码——中间发生了什么？通过分析一次完整任务执行过程中 Claude Code 与 LLM 之间的完整交互日志，我们蒸馏出了 6 个关键机制。

发现 1：多指令分割与 JSON 完整性保证​

当用户同时发出多个指令时（比如"先创建项目结构，再写配置文件，最后跑测试"），Claude Code 需要确保每个指令都被正确执行，且不会因为 JSON 格式不完整而中断。

机制：

• 指令被分割为独立的任务单元，每个单元有明确的开始和结束标记
• 在执行过程中，Claude Code 维护一个 JSON 缓冲区，只有确认当前单元的 JSON 完整后才提交
• 如果 JSON 不完整（模型输出被截断），Claude Code 会发起补全请求，而不是直接失败

启示：AI 编程工具的可靠性很大程度上取决于输出完整性校验。模型本身是不可靠的（可能截断、可能格式错误），工具层必须做校验和补全。

发现 2：上下文压缩与任务连贯性​

随着任务执行，上下文会越来越长。Claude Code 怎么处理？

机制：

• 不是简单截断，而是语义压缩——保留关键决策点、删除冗余的中间推理步骤
• 压缩时保持任务的"连贯性"——即使删除了某些中间步骤，模型仍然知道"现在进行到哪一步"
• 使用一种类似"摘要 + 锚点"的策略：用摘要概括已完成的工作，用锚点标记当前进度

启示：上下文管理不是"删旧留新"，而是"保留决策链路"。好的上下文管理让模型不会"失忆"。

发现 3：工具列表的动态呈现​

Claude Code 不会把所有可用工具一次性灌给模型。

机制：

• 根据当前任务阶段，动态选择哪些工具对模型可见
• 比如写代码阶段，文件操作工具优先级高；部署阶段，Shell 命令工具优先级高
• 工具描述中包含使用约束（比如"这个工具只能读，不能写"），减少误用

启示：不是给模型"所有能力"，而是给模型"当前需要的能力"。能力过多反而增加混淆和错误率。

发现 4：System Prompt 的层次结构​

Claude Code 的 System Prompt 不是一个大段落，而是分层的：

• 身份层：你是谁（编程助手）、你的目标是什么
• 规则层：你必须遵守的规则（比如"先思考再行动"、"不确定的事情问用户"）
• 工具层：你能调用哪些工具、每个工具的契约
• 格式层：你的输出必须是什么格式（JSON schema 等）

启示：System Prompt 的层次化设计让模型更容易理解自己的角色边界。这也是为什么 CLAUDE.md 能生效——它补充了规则层的内容。

发现 5：流式输出中的并行工具调用​

在用户看到流式输出的同时，Claude Code 在后台并行执行多个工具调用。

机制：

• 模型输出一个"计划"（接下来要做 A、B、C），Claude Code 解析计划
• 如果 A、B、C 之间没有依赖关系，并行执行
• 流式输出给用户的是"正在做什么"的进度，而不是等待所有工具执行完才输出

启示：流式输出的核心价值不是"让用户看到 token 逐字出现"，而是让用户知道系统正在工作，同时后台最大化并行度。

发现 6：压缩后的任务连贯性​

这是发现 2 的补充。上下文压缩后，Claude Code 如何确保模型不"迷路"？

机制：

• 每次压缩时生成一个"进度快照"——当前状态、已完成项、待办项、阻塞项
• 这个快照作为新的上下文的"锚点"，模型以此为起点继续推理
• 快照中包含关键的决策理由（为什么选了 A 方案），防止模型在后续执行中做出矛盾的决策

启示：决策理由的保留比决策结果更重要。模型可能忘记"做了什么"，但只要记得"为什么这么做"，就能保持一致性。

对 FDE 的启示​

如果你要自己搭建一个类似 Claude Code 的系统，这 6 个发现直接对应了你需要解决的技术问题：

这些问题不是"大模型"的问题，而是工程系统的问题。这也正是 FDE 岗位的核心价值——把概率模型变成可靠的工程系统。

总结​

Claude Code 看起来"智能"的背后，是一层又一层的工程机制在支撑。模型提供了"理解"和"生成"的能力，但可靠性、效率、用户体验，全靠工具层的工程实现。

这 6 个发现告诉我们：AI 编程工具的竞争力不在于"用了多大的模型"，而在于工程机制的设计质量。

模型很强，但系统不能只靠模型。安全不是模型的属性，是系统的属性。

前言​

在上一篇"铁律"文章里，我提到了 Harness 的四层架构——连接、编排、效能、安全。当时说会专门写一篇文章展开这个话题。今天就来兑现。

模型本身的能力在不断进化。但一个反复出现的模式是：你在实验中看到的模型表现，和它进入生产系统之后的表现，往往差距巨大。不是模型变笨了，是生产环境比实验室复杂得多。

传统软件系统里，代码的行为是确定性的——同样的输入，同样的输出。但 AI 系统的核心组件是概率模型。同一个 prompt，两次调用的结果可能不同。模型可能被用户输入诱导，忽略系统指令。它可能在总结文档时把恶意命令当成更高优先级的指令。它可能调用了本该只读的工具，却因为参数组合触发了写操作。

这些问题不是"等模型再聪明一点"就能解决的。只要模型的行为是不可完全预测的，系统就需要在模型之外建立确定的边界。这篇文章从连接、编排、效能、安全四个维度，完整呈现生产级 AI 系统的工程实践。

一、连接——让模型的意图进入真实世界​

模型的输入和输出都是 token，但生产环境不止是 token。数据库里有记录，文件系统里有路径，浏览器里有页面状态，业务系统里有流程和接口。模型可以生成"查一下这个订单"、"打开这个页面"、"让测试 Agent 跑一下"，但这些表达本身不会触发任何真实动作。

连接层解决的就是这个问题：把外部能力变成模型可理解、可调用、可返回的语义接口。

模型往外调用时，token 输出要被转换成外部系统能接收的调用——API 请求、文件读写、浏览器动作、shell 命令，或者对另一个 Agent 的语义化调用。返回给模型时，外部系统的状态和结果也要被转换成模型能继续理解的输入。

Tool Calling、MCP、A2A、环境接口——它们面对的对象不同，但解决的是同一件事：把外部能力包装成模型可通讯的对象。从工程角度看，Harness 必须具备连接能力，是因为模型本身不会天然拥有这些通道。没有连接层，模型只能生成文本；有了连接层，已有的数字资产、运行环境和其他 Agent 才能被包装成模型可理解、可调用、可返回的语义接口。

连接的力量有多大？一个团队用 Water 这个工具，通过 Agent 自动逆向还原了 Cursor 的完整 gRPC 协议与 Agent 架构。用 AI 分析 AI，用 Agent 理解 Agent——这在一年前是不可想象的。连接的威力在于，它让模型不仅能操作已知的系统，还能自主探索和理解未知的系统。

但连接也是风险的入口。当模型可以调用任何外部系统时，一次错误的参数组合可能触发破坏性操作。这就是为什么连接层必须与安全层紧密配合——能连什么、能调什么、能改什么，都需要明确的权限约束。

二、编排——为概率行为建立确定性的过程​

短任务里，模型的一次回答、一次工具调用，和用户期待的结果之间距离很近，编排问题不明显。但如果让 Agent 修一个复杂 bug，情况就完全不同了。它要读代码、定位问题、修改实现、运行测试、根据失败日志继续修、更新文档、提交变更。

这时候暴露出来的问题是：任务时间线无法只靠模型自己维持。它可能忘记已经尝试过哪些方案。在测试失败后回到错误路径。因为上下文被压缩，丢掉用户最初的约束。或者看见某个文件已修改，就误以为任务已经完成。

编排层要做的，就是把这部分原本依赖人持续维持的过程控制，外化成系统结构。

围绕任务推进的整个过程，有几个问题不会随着模型的发展而消失：

任务边界。 一个 Agent 任务不等于一轮聊天，也不等于一次模型调用。系统必须知道现在到底在执行哪件事：目标是什么，约束是什么，当前阶段在哪里，什么条件下算完成。没有任务边界，Agent 就很容易把局部动作误认为整体进展。

过程状态。 长任务需要一个外部状态机来记录任务推进到哪里：哪些步骤已经完成，哪些方案已经失败，哪些工具返回过什么结果，哪些约束仍然有效。只有这些状态被外部化，Agent 才不会在上下文变化、会话中断或压缩之后重新迷路。

下一步选择。 系统必须决定接下来往哪里走。这个决定可以由预定义流程给出，也可以由模型判断，也可以由规则、评估器、人类审批共同决定。Workflow、DAG、State Machine、ReAct、多 Agent 协作，都是不同时期对这个问题的实现方式。形式会变，但"下一步如何被选择"这个问题不会消失。

异常恢复。 长任务一定会遇到偏差：工具超时、权限不足、测试失败、上下文丢失、模型跑偏、外部系统状态变化。编排层必须能让任务暂停、重试、回滚、降级、切换路径、请求人工介入，而不是把每一次失败都变成从头再来。

结果验收。 Agent 自己说"完成了"不一定可信。系统需要用测试、检查项、评估器、预算、超时、循环次数、外部反馈来判断任务是否应该继续。它们的作用不是节省推理成本，而是决定这一步能不能进入下一步、任务是否真的完成。

在 Agent Harness Cluster 的架构中，编排层的作用更加关键——多个 Agent 之间的任务分配、依赖管理、状态同步，都需要一个中心化的编排机制来协调。

三、效能——用确定性复用替代重复推理​

设想一个理想状态：你有一个足够强的大模型，也有一个非常耐心且懂业务的人类。这个人会不断给模型补充背景，纠正方向，解释团队习惯，提供资料，判断下一步该怎么走。再加上连接和编排，这个组合理论上可以解决所有问题。

但问题也很明显：它的能量消耗太大了。不只是 token，还包括人类反复解释背景的时间，补充资料的时间，纠偏的注意力，模型处理长上下文的推理成本，以及每次从零规划带来的等待和返工。

效能层的核心原则是：用确定性的复用，替代重复的人类劳动和重复的 GPU 推理。

上下文管理负责减少重复解释。Context Engineering 不是把信息塞满上下文窗口，而是决定每一步模型应该看什么、不该看什么、以什么结构看。好的上下文应该像一张结构化地图：让模型快速知道项目在哪里、规则是什么、当前任务处于什么位置，而不是依赖人类每轮重新铺背景。这和"铁律"文章中 Claude Code 的上下文压缩机制是同一问题的不同解法——Claude Code 在会话内部做压缩，而上下文管理在系统层面做分级。

记忆和 RAG负责减少人工找资料。Memory / RAG 的价值不是"让 Agent 什么都记住"，而是在需要时找回相关知识。长期记忆、短期状态、知识库检索、代码索引、历史任务记录，都是为了减少人类手动贴资料、补上下文、解释历史决策的次数。

缓存负责减少重复计算。Prompt Cache、Result Cache、Embedding Cache 都属于确定性复用。同样的系统提示、同样的检索结果、同样的工具元信息、同样的格式转换，不应该每次都重新付出完整推理成本。Prompt Cache 的工程实践表明，合理的缓存策略可以将重复任务的推理成本降低 60% 以上。

模型路由负责减少不必要的大模型调用。不是所有步骤都需要最强模型。格式修复、小段摘要、检索重排、上下文压缩、简单分类，可以交给更便宜更快的模型，甚至交给规则和脚本。复杂规划、关键判断、高风险生成，再交给强模型。Model Router 的意义，是让系统在效果、成本、延迟之间动态取平衡。

Skill负责固化人类经验。Skill 不是简单的 prompt 包，而是把人类过去反复指导模型的经验沉淀下来：这个任务通常怎么做，哪些文件要先看，哪些命令要运行，哪些约束不能破坏，什么样的结果算合格。当某类任务被反复验证，就应该沉淀成 Skill、脚本、Workflow 或模板。

规则和脚本负责把 GPU 推理卸载到 CPU 执行。很多事情不需要模型猜：字段校验、格式转换、权限判断、固定 SOP、批处理、数据搬运、测试命令执行，都可以由确定性程序完成。能用 CPU 上的确定性执行解决的，就不应该每次都让 GPU 上的大模型重新推理。

效能层的本质是把高成本的人类指导和模型推理，沉淀为可复用、可执行、可缓存、可路由的确定性结构。

四、安全四层防线——把概率行为限制在确定边界内​

安全一直是技术落地真实生产最基本的要求。特别是当 Agent 开始自主地处理企业数据、执行代码、调用内部系统、写数据库时，安全显得更加重要。

一个团队对 15 款主流 Agent 模型做了安全与可用性实测，发现了一个关键事实：不同模型在安全性上的短板差异显著。有的模型安全认知较强，却更容易产生幻觉；有的模型对指令过度服从，可能导致破坏性越权行为。这意味着——即使是最强的模型，也不能把安全责任交给它自己。

安全层需要建立四层防线：

第一层：输入侧防注入和上下文隔离。 用户输入、网页内容、检索文档、工具返回值，都不能天然等同于可信指令。Harness 需要区分指令与数据，标记不同上下文来源的可信等级，防止外部文本改变 Agent 的行为规则。如果系统只靠 prompt 告诉模型"不要这样做"，那其实是在把安全责任交给概率输出。生产系统不能这样设计。

第二层：输出侧结构化约束。 Schema、parser、validator、guardrails 的意义，是让模型输出必须通过确定性检查才能进入下一步。模型可以生成概率内容，但进入系统边界时必须被转换成可验证的结构。一旦字段缺失、类型错误、越过枚举范围、违反业务规则，就应该被截断、修复或要求重试。

第三层：执行侧权限和沙箱。 工具调用真正落地时，必须受 Auth、Policy、Sandbox、Quota 约束。能读的不能写，能查个人数据的不一定能查全量数据，能运行脚本的不一定能访问网络，能创建草稿的不一定能发送邮件。即使模型输出了危险动作，执行环境也要把影响范围限制住。

第四层：高风险动作人在回路，全链路审计。 Human-in-the-Loop 不是为了显得保守，而是因为很多业务动作的风险无法仅靠模型或规则判断。付款、删除、外发、权限变更、生产发布——这些动作需要审批点。Agent 可以准备材料、给出建议、生成 diff，但最终授权要由系统策略或人类确认。Audit Log 不是事后补丁，而是 Agent 能否进入生产的前提。

安全层解决的问题是：当模型行为不可完全预测时，系统如何保证权限、数据、动作和责任边界仍然是确定的。安全决定了 Agent 停留在实验原型，还是能够进入生产系统。

五、模型选型——15 款 Agent 模型的安全实测启示​

回到那 15 款模型的实测。为什么要测这么多模型？因为大模型是 Agent 的"决策大脑"，而不同模型在安全性上的短板差异显著。

测试发现了几类典型的安全模式：

安全认知强但幻觉倾向高。 这类模型知道什么是危险操作，能识别大部分越权请求，但在某些边界情况下会给出看似合理实际上错误的回答。幻觉在 Agent 场景中特别危险——因为模型不只是生成文本，还会基于幻觉内容执行真实操作。

过度服从指令。 这类模型对用户的几乎所有指令都会执行，包括破坏性的。在聊天场景中这可能只是输出不当内容，在 Agent 场景中这可能导致文件删除、数据泄露、系统破坏。

安全认知与执行能力不匹配。 这类模型能识别出某个操作有风险，但没有能力采取替代方案——它知道不能做 A，但不知道应该做 B。结果就是卡住或者给出无用的回答。

这些发现对模型选型的启示是：Agent 场景的模型选型不能只看 benchmark 分数。安全性 profile——包括注入抵抗力、越权识别率、幻觉率、过度服从倾向——和推理能力同等重要。

一个可行的选型方法是：先根据业务需求确定能力基线（代码质量、推理能力、工具调用准确率），然后在达标模型中比较安全性 profile，最后根据风险容忍度做权衡。高风险场景（金融、医疗、基础设施）应该优先安全性，低风险场景（个人工具、原型开发）可以优先能力。

结语​

模型很强，但系统不能只靠模型。

连接让模型的意图进入真实世界，编排为概率行为建立确定性的过程，效能用确定性复用替代重复推理，安全把概率行为限制在确定边界内。这四根支柱——连接、编排、效能、安全——构成了把概率模型放进生产系统的完整框架。

它们不是四个独立模块，而是交织在同一条执行链路上。纵向看，编排建立在连接之上，效能横跨两者。横向看，安全决定每一步能不能做。四层之间存在天然张力：效能追求复用，安全要求隔离；编排追求自主推进，安全要求关键节点停下来等人确认。好的设计不止是让四层各自最优，而是在张力中找到适合具体场景的平衡。

模型在进化，很多今天需要精心编排的问题，明天可能被更强的推理能力自然消解。但这四类问题本身不会消失——只要你把概率模型放进生产系统，连接、编排、效能、安全就一定会以某种形式出现。

如何围绕自己的业务场景，把这套框架落地，就是你的 Harness。