Coding Agent 三大支柱：Context、Subagents 与 Harness 工程实践
1. 这不是“更聪明的补全”，而是开发范式的地壳运动
去年春天，我第一次在团队晨会里演示用 Claude Code 自动重构一个遗留模块的 service 层——不是写新功能，是把散落在三个文件里、命名混乱、职责交叉的逻辑，按 DDD 分层原则重新组织。整个过程我只做了三件事：写了一条清晰的指令、确认了它生成的 plan、最后扫了一眼 diff。不到八分钟，代码结构焕然一新，测试全绿。当时会议室里一片安静，不是因为震撼，而是因为一种熟悉的、被技术颠覆时的轻微眩晕感。这种感觉，和十年前第一次看到 Git 的 staging area 时一模一样：它没解决新问题，但它彻底改写了我们和“代码”这个东西打交道的基本契约。
Coding Agent 已经越过“辅助工具”的临界点，正在成为一套全新的软件交付操作系统。你手里的 IDE 不再是编辑器，而是一个调度中心；你写的代码不再只是逻辑载体，更是给 agent 提供 context 的元数据；你日常做的 code review，正从“检查实现是否正确”，悄然转向“校验 context 是否完备、harness 是否牢靠”。这不是渐进式优化，是范式转移——就像当年从瀑布走向敏捷，表面看是流程变化，底层是信任模型、责任边界与风险控制逻辑的全面重写。
过去一年，行业里所有热闹的名词——Context Engineering、Subagents、Harness——都不是孤立的技术点，它们是一套精密咬合的齿轮组，共同驱动着这场转移。Context Engineering 解决的是“喂什么”，Subagents 解决的是“怎么分派”，Harness 解决的是“如何兜底”。三者缺一不可，任何单点突破都只能带来局部效率提升，而无法支撑起企业级的、可持续的 AI 原生开发。这也是为什么，单纯堆砌 prompt 技巧或迷信某个大模型参数，会在真实项目中迅速撞墙：你喂得再精准，没有 subagents 去拆解复杂任务，context 就会像塞满的行李箱，越用力关越弹开；你设计再精巧的 subagents，没有 harness 做确定性约束，产出就永远带着“青少年式”的任性——它听懂了你的字面意思，却完全误解了你的意图。
我见过太多团队卡在这个认知断层上。他们花大力气定制了一套华丽的 rules.md 和 skills 目录，结果 agent 在执行一个简单的数据库迁移脚本时，因为没加载正确的 CLI skill，直接在生产库上执行了DROP TABLE。事后复盘，问题不在 rules 写得不够细，而在于整个 workflow 缺少一个最基础的 harness：一个强制的、不可绕过的沙箱执行环境，以及一条硬性规则——“所有涉及DROP或ALTER的 SQL，必须在本地 dockerized DB 中预演并通过 schema diff 验证”。这根本不是 LLM 能力问题，是系统设计的缺失。
所以，这篇文章不打算罗列“10 个必学的 Coding Agent 技巧”。我要带你钻进这套新操作系统的内核，看清 Context Engineering 如何从“写文档”变成“写工程接口”，Subagents 如何从“多开几个窗口”升级为“分布式任务编排”，Harness 又如何从“加个 try-catch”进化成覆盖开发全生命周期的信任基础设施。你会看到，真正的瓶颈从来不在模型本身，而在于我们能否用工程思维，为非确定性的智能体，构建出确定性的运行轨道。
2. Context Engineering：从“写说明书”到“建接口协议”
去年 QCon London 上，我还把 Context Engineering 理解成一份更高级的 README.md——无非是把团队规范、常见坑点、项目结构说明，用 Markdown 整理好，丢给 agent 当“参考书”。这种理解，在今年春天一个周五下午被彻底击碎。那天，我让 agent 基于一份模糊的需求文档，为一个微服务添加新的 Kafka 消费者。它生成的代码逻辑完美，但部署后消费者始终无法启动。排查了两小时，发现它在application.yml里错误地配置了spring.kafka.bootstrap-servers的值，指向了一个早已下线的测试集群。我翻遍了所有 rules.md，里面确实有一条：“Kafka 配置请严格参照config/kafka/README.md”。可问题就出在这里——config/kafka/README.md本身，就是一份过期三个月的文档。
这个 Bug 揭示了早期 Context Engineering 的致命软肋：它把上下文当作静态知识库，而非动态可验证的接口。当知识源（如 README）本身失真、滞后或碎片化时，“精心筛选的信息”反而成了最危险的幻觉。真正的 Context Engineering，其核心已悄然转向定义和维护一套 agent 可理解、可调用、可验证的 context 接口协议。它不再是“告诉 agent 我们怎么做”，而是“教会 agent 如何自己找到正确答案”。
2.1 Skills：从文档片段到可执行模块
Skills 是这一转变最直观的载体。Anthropic 提出的 Skills 概念，绝非仅仅是把一个大 rules.md 拆成小文件夹这么简单。它的本质，是将“知识”封装成一个具备明确输入、输出、副作用和生命周期的最小可执行单元。
以我修复 Kafka 配置问题为例，旧方案是写一段文字：“Kafka 集群地址请查 config/kafka/README.md”。新方案则是一个名为kafka-config的 skill 文件夹：
skills/kafka-config/ ├── description.md # 对 LLM 的简短描述："获取当前环境有效的 Kafka bootstrap servers 地址" ├── get-bootstrap-servers.sh # 可执行脚本，能根据当前 profile (dev/staging/prod) 动态查询 ├── schema.json # 定义脚本输出的 JSON Schema，确保 agent 能解析 └── test/ # 该 skill 的独立测试用例 └── test_dev_mode.sh关键变化在于：
- 惰性加载（Lazy Loading）：agent 初始 session 只看到
description.md的几行文字。只有当它在规划阶段判断“需要获取 Kafka 地址”时，才会触发加载整个kafka-configskill，并执行get-bootstrap-servers.sh。这避免了将所有可能用到的 context 一股脑塞进初始 prompt，极大缓解了 context window 压力。 - 可执行性（Executability）：
get-bootstrap-servers.sh不是给人看的文档，是给机器跑的程序。它能连接内部配置中心 API，实时拉取最新值，甚至能 fallback 到本地.env文件。agent 得到的不是静态文本，而是动态、可信、带版本的实时数据。 - 可验证性（Verifiability）：
schema.json强制规定了脚本输出格式。如果脚本返回了{"servers": ["old-broker:9092"]}，而 schema 要求{"bootstrap_servers": ["string"]}，agent 会立刻报错并拒绝使用该结果，而不是将错就错。
提示：不要试图用 Markdown “描述”一个 CLI 工具的用法。直接把
curl -X GET https://config-api/internal/kafka?env=prod的逻辑，封装成一个健壮的 shell 脚本，并让它成为 skill 的一部分。LLM 的强项是规划和决策，不是记忆命令参数。
2.2 Context Interfaces：让 LLM 学会“看菜单点菜”
Skills 只是食材，Context Interfaces 才是餐厅的菜单。LLM 不可能记住所有技能的细节，它需要一个清晰、结构化的“能力目录”，来指导它何时、调用哪个 skill。这催生了多种 interface 标准：
- MCP（Model Context Protocol）：这是目前最成熟的协议。它定义了一套标准的 JSON-RPC 接口，让 agent 可以通过统一方式发现、调用外部工具。例如，一个 MCP server 可以暴露
list_repos,get_file_content,run_tests等方法。agent 只需知道这个 server 的 endpoint，就能像调用函数一样使用它，无需关心背后是 GitHub API 还是本地 git 命令。 - Tool Calling（工具调用）：Claude Code、Cursor 等内置的 tool calling 机制，本质上也是一种 interface。它要求你为每个 CLI 工具（如
eslint,docker-compose）提供一个 JSON Schema，精确描述其名称、参数、描述和返回格式。LLM 会基于用户指令和当前 context，自动选择并填充参数调用这些工具。 - Language Server Protocol (LSP) 集成：这是最高阶的 interface。当你把 IntelliJ 的重构能力（如
rename symbol）通过 LSP 暴露给 agent，你赋予它的就不再是“文本替换”的能力，而是“语义感知的重构”能力。它能理解变量作用域、类型继承关系，做出远超正则表达式的精准修改。
这些 interface 的共同目标，是将“人类的知识”翻译成“机器可消费的契约”。一个优秀的 Context Engineer，其工作重心已从“写多少文档”，转向“设计多少个清晰、稳定、可测试的 interface”。我团队现在有一个硬性规定：任何新引入的外部数据源（如内部文档站、API 文档、监控大盘），必须配套提供一个 MCP server 或至少一个标准化的 CLI tool，否则不被视为可用的 context。
2.3 Context Budgeting：在 token 的钢丝上跳舞
Context window 的扩大，是把双刃剑。去年，我们曾天真地认为 200K token 意味着可以“把整个代码库塞进去”。实测结果惨痛：当初始 context 达到 150K token 时，agent 的响应质量断崖式下跌，plan 阶段变得异常冗长且容易偏离主题，成本也飙升至无法承受。原因很简单：LLM 的注意力机制并非线性分配。当 context 过载，它会优先关注开头和结尾的“高亮”信息，而中间大量精心准备的 rules 和 skills，反而成了干扰噪音。
因此，“Context Budgeting”（上下文预算管理）已成为一项核心工程实践。我们不再问“这个 skill 重要不重要”，而是问“这个 skill 在本次任务中的 ROI（投入产出比）是多少？”。具体操作上，我们建立了三层预算体系：
| 预算层级 | 占比 | 内容 | 管理策略 |
|---|---|---|---|
| 固定开销（Fixed Overhead） | ~20% | System Prompt, Agent Identity, Core Principles (e.g., "Never modify prod without approval") | 由平台团队统一维护，不可压缩 |
| 动态技能（Dynamic Skills） | ~50% | 按需加载的 skills（如kafka-config,db-migration） | 严格限制每个 skill 的 size < 2K token；使用description.md+schema.json替代冗长文档 |
| 任务上下文（Task Context） | ~30% | 当前 PR 的 diff, 相关 issue 描述, 关键日志片段 | 采用“摘要+引用”模式：只放 3 行关键日志，附上tail -n 100 logs/error.log | grep 'ERROR'命令供 agent 按需执行 |
注意：Claude Code 的 context monitor 功能是我们的救命稻草。它能实时显示每个 component 的 token 占用（如
system_prompt: 1248,skill_kafka-config: 892,current_diff: 3210）。我们要求所有工程师在开启新 session 前，必须先看一眼这个面板。如果current_diff占了 70%，那第一件事就是删掉无关的 log 行，而不是抱怨 agent “不聪明”。
3. Subagents：从“多开窗口”到“分布式任务编排”
“Subagents”这个词刚出现时，我下意识把它等同于“多开几个 Claude Code 窗口”。直到亲眼看到一个 subagent 在 17 分钟内，独自完成了对一个包含 237 个文件的遗留 Java 项目的完整依赖图谱分析、识别出 12 个高风险的循环依赖环、并自动生成了 8 个针对性的重构建议——而主 agent 在此期间，只负责接收最终报告、评估建议可行性，并向我发出一个简洁的 summary。那一刻我才明白，subagents 的本质，不是“更多 agent”，而是将一个单点、串行、易受干扰的智能体，解耦为一个专注、并行、可隔离的分布式任务网络。
3.1 Subagents 的三种核心角色：探索者、审查者与执行者
Subagents 并非千篇一律。根据其承担的任务性质和与主 agent 的交互模式，我们将其归纳为三大类，每类都有截然不同的设计哲学和安全要求：
Explorer（探索者）：这是最常见、也最“安全”的 subagent。它的唯一使命是“获取信息”，绝不产生任何副作用。典型场景包括：
codebase-explorer：扫描整个 repo，构建 AST、提取模块依赖、识别技术栈。它产生的输出是纯数据（JSON 格式的依赖图），主 agent 用它来制定后续计划。log-analyzer：连接到 ELK 或 Datadog，执行预设的查询语句，返回聚合后的错误率、慢查询 Top 10。它不会修改任何日志，也不会触发告警。
Explorer 的设计要点是极致的隔离与轻量。我们通常为其分配一个极小的 context window（< 5K token），只包含必要的查询指令和 schema。它被严格限制在只读沙箱中，无法访问任何写权限。它的失败成本最低——大不了重试一次。
Reviewer（审查者）：这是建立信任的关键一环。它的任务是“评估质量”，同样不产生副作用，但其输出直接影响主 agent 的决策。典型场景包括：
security-reviewer：专门检查 PR diff 中是否存在硬编码密钥、不安全的反序列化调用、或潜在的 SSRF 漏洞。它使用一套定制的 Semgrep 规则集，输出是带行号的漏洞列表。arch-reviewer：基于 ArchUnit 规则，检查新代码是否违反了分层架构（如 domain 层是否意外依赖了 infra 层）。它的输出是结构化的违规报告。
Reviewer 的设计要点是确定性与可解释性。它必须基于 CPU-based 的静态分析工具（如 Semgrep, ArchUnit, ESLint），而非 GPU-based 的 LLM 推理。它的报告必须包含清晰的规则 ID、触发位置和修复建议。我们要求所有 reviewer 的输出，必须能被人类工程师在 30 秒内理解并验证。
Executor（执行者）：这是风险最高、也最具价值的 subagent。它的使命是“完成任务”，会产生真实的副作用（修改文件、执行命令、部署服务）。典型场景包括：
test-runner：在隔离的 Docker 环境中，执行mvn test -Dtest=MyServiceTest，并返回详细的测试报告（通过/失败、覆盖率、耗时）。codemod-executor：应用 OpenRewrite recipe，批量重命名一个类的所有引用。它必须在一个临时分支上运行，生成完整的 diff，由主 agent 审核后才合并。
Executor 的设计要点是沙箱化与原子性。它绝不能在主工作区直接执行。我们强制所有 executor 运行在 ephemeral（临时）的容器或 git branch 中。每一次执行，都必须是一个原子操作：要么全部成功并提交一个干净的 commit，要么全部失败并回滚，不留任何中间状态。它的输出必须是可审计的、可重现的。
3.2 Orchestrating the Swarm：主 agent 的编排艺术
Subagents 的威力，不在于单个有多强，而在于主 agent 如何像一个经验丰富的指挥官，将它们编织成一张协同作战的网络。这被称为Orchestration（编排），是当前最前沿、也最缺乏成熟工具的领域。
一个典型的、经过良好编排的 subagent workflow 如下（以修复一个线上 P0 故障为例）：
- 主 agent 启动：收到告警
service-x latency > 2s。 - 派生 Explorer：
log-analyzersubagent 被创建，查询最近 15 分钟的 error logs 和 slow traces。它返回一个关键线索："java.lang.OutOfMemoryError: Metaspace"。 - 条件分支：主 agent 基于
OutOfMemoryError这一关键词，决定下一步行动。它没有盲目派生jvm-tuner，而是先派生codebase-explorer，去查找所有近期修改了 JVM 参数的配置文件。 - 并行审查：主 agent 同时派生两个 reviewer：
security-reviewer：检查新配置文件中是否有硬编码的敏感信息。arch-reviewer：检查该配置变更是否符合“配置即代码”的架构原则（如是否存放在config/目录下，而非src/main/resources/）。
- 执行与验证：只有当两个 reviewer 都返回“通过”时，主 agent 才会派生
jvm-tunerexecutor。它在沙箱中应用新参数，运行load-test，并将结果（TPS、P99 latency、GC 日志）返回给主 agent。 - 决策闭环：主 agent 综合所有 subagent 的报告，生成一个最终决策：
"建议将 -XX:MaxMetaspaceSize 从 256m 调整为 512m，并在 config/jvm-prod.yml 中更新。已生成 PR #1234。"。
这个过程之所以高效，是因为主 agent 将一个复杂的、需要人类专家经验的故障排查，分解为一系列可并行、可验证、可失败的原子任务。每个 subagent 只需精通一个狭窄领域，而主 agent 的智慧，体现在它对任务流的精准判断和路由上。
提示：不要试图让一个 subagent “做所有事”。我见过最失败的设计，是一个名为
all-in-one-fix的 subagent，它被要求“分析日志、定位代码、修改配置、运行测试、生成 PR”。结果它在第一步就卡死在日志分析上，整个流程停滞。正确的做法是，让log-analyzer专注日志，code-finder专注代码，config-updater专注配置——每个都是小而美的乐高积木。
4. Harness：从“加个 try-catch”到构建信任基础设施
如果说 Context Engineering 是给 agent “喂食”，Subagents 是给 agent “分工”，那么 Harness 就是给 agent “立规矩、装护栏、配保险”。它是整个 Coding Agent 范式中最关键、也最容易被低估的一环。没有 Harness，再强大的 Context 和再精妙的 Subagents，都只是在悬崖边高速行驶的赛车——动力十足，但毫无安全感。
Harness 的核心思想，源于一个朴素的观察：我们无法让非确定性的 LLM 产出 100% 确定的结果，但我们可以通过确定性的、CPU-based 的工程手段，来约束、验证、修正和兜底其产出。它不是一个单一工具，而是一套覆盖开发全生命周期的、分层的信任基础设施。
4.1 Harness 的四层防御体系
我们团队将 Harness 构建为一个清晰的四层防御体系，每一层都针对不同维度的风险，且层层递进：
| 防御层级 | 核心目标 | 关键组件 | 实战案例 |
|---|---|---|---|
| L1: 输入净化（Input Sanitization） | 防止恶意或低质 context 污染 agent | MCP Server 的输入过滤器、CLI Tool 的参数白名单、Prompt Injection 检测器 | 当github-issue-handlersubagent 接收一个外部 Issue 时，L1 层会自动移除所有<script>标签、URL 编码的特殊字符，并对@符号后的内容进行沙箱化处理，防止攻击者通过@user注入指令。 |
| L2: 过程约束（Process Constraints） | 确保 agent 的行为符合工程规范 | 结构化测试（Structural Tests）、ArchUnit 规则、自定义 Linters、强制的 CI/CD Gate | 在 agent 生成新代码后，L2 层的arch-linter会立即运行。如果它检测到domain/model/User.java直接 import 了infra/db/DatabaseConnection.java，则阻断整个流程，要求 agent 重新设计。这不是 bug，是架构 violation。 |
| L3: 输出验证（Output Verification） | 验证 agent 产出的功能正确性 | 自动化端到端测试（E2E）、Contract Testing、Schema Validation、性能基线对比 | api-generatorsubagent 创建了一个新的 REST endpoint。L3 层会自动触发一个 Contract Test，验证其响应 JSON 是否符合 OpenAPI spec 定义的 schema，并且响应时间是否在 200ms 基线内。 |
| L4: 运行时防护（Runtime Safeguards） | 为 agent 的执行提供安全、隔离的环境 | Dev Containers、Docker-in-Docker (DinD) 沙箱、Network Policy、Secrets Management | 所有executorsubagents 必须在 L4 沙箱中运行。该沙箱默认禁用网络访问，若需调用外部 API，则必须通过一个预批准的、带 rate-limiting 的代理服务。所有 secrets（如 DB password）均通过 HashiCorp Vault 注入，而非明文环境变量。 |
这四层并非静态存在，而是形成一个动态反馈闭环。L2 的 lint 错误会作为 feedback，被送回给 agent，用于改进其后续的 coding style；L3 的 E2E 失败会触发 L1 的 context 重新评估，看是否是需求描述不清导致；L4 的沙箱日志会被收集，用于训练更精准的 L1 过滤器。
4.2 Harness Engineering：一门新兴的工程学科
Harness Engineering 正在迅速成为一门独立的、高价值的工程学科。它的从业者，既不是传统的 SRE，也不是纯粹的 AI 工程师，而是两者的融合体——他们需要深刻理解软件架构、CI/CD 流水线、安全合规，同时也必须精通 LLM 的行为模式、prompt engineering 和 agent workflow 设计。
我们团队为此设立了一个专门的 Harness Engineering 小组，其核心工作包括：
- Harness-as-Code（HaaC）：将所有 Harness 规则、配置、测试用例，全部用代码（YAML/JSON/Terraform）定义，并纳入版本控制。一个
harness/目录，和src/、test/并列，是代码库的“第三支柱”。这意味着，当一个新的微服务被 scaffolded 时，它自动继承一套预定义的 Harness 模板（如java-spring-boot-harness），包含了从 L1 到 L4 的全部配置。 - Harness Generation：利用 AI 来生成 Harness 本身。这听起来有点“用魔法打败魔法”，但效果惊人。例如，我们给一个 LLM 提供一份《公司前端架构规范》的 PDF，让它生成一套对应的 ESLint 规则和 Cypress E2E 测试模板。生成的 Harness 质量可能不如资深工程师手写，但它的速度和覆盖广度，是人力无法企及的。更重要的是，它降低了 Harness 的准入门槛，让每个业务团队都能快速拥有自己的“安全网”。
- Harness Telemetry & Feedback Loop：在每一个 Harness 层级，都埋入精细的 telemetry。我们不仅记录“这个 lint 规则失败了多少次”，更记录“失败时 agent 的输入 context 是什么”、“失败后 agent 修改了哪几行代码”、“修改后的代码是否通过了下一层的验证”。这些数据汇聚成一张“Harness Effectiveness Map”，让我们能精准地看到：哪些规则是真正有用的（高频触发、高修复率），哪些是形同虚设的（从不触发，或触发后 agent 无法修复），从而持续优化整个 Harness 体系。
提示：不要把 Harness 当作“额外负担”。我们做过一个实验：在两个功能相似的团队中，A 团队坚持手工编写所有代码，B 团队全面启用 Harness 驱动的 Coding Agent。半年后，B 团队的代码库熵值（通过 dependency-cruiser 计算）下降了 37%，而 A 团队上升了 12%。Harness 不是拖慢速度的枷锁，而是防止代码库在自动化浪潮中失控的压舱石。
5. 范式转移的代价：当“更快”开始侵蚀“更好”
范式转移从来不是一场纯粹的狂欢。它在慷慨地馈赠效率红利的同时，也悄然埋下了新的、更隐蔽的代价。过去一年，我目睹了太多团队在拥抱 Coding Agent 后，陷入一种甜蜜的陷阱：PR 数量翻倍、上线速度加快、周报上的“AI 贡献度”数字亮眼……但与此同时，代码库的“气味”开始变差——模块边界日益模糊，重复逻辑悄然滋生，技术债的利息以指数级增长。这并非 AI 的错，而是我们尚未学会在新范式下，重新定义“质量”与“速度”的平衡点。
5.1 “Goldilocks 速度”：刚刚好的节奏
“快”是 Coding Agent 最诱人的承诺，但“过快”却是最危险的陷阱。Amazon 内部那份关于 AI 故障的复盘报告，其核心结论令人警醒：他们增加 senior engineer 的强制 review 关卡，并非为了“拖慢”，而是为了对抗一种新型的、由速度压力催生的“认知捷径”。当管理者不断追问“你的 AI 产出是什么？”，当团队 KPI 被绑定在“每周 merge 的 PR 数量”上，工程师的本能反应，就是关闭那些耗时的、深度的、需要思考的环节——比如，跳过对 agent 生成的测试用例的逐行审查，直接点击“Approve”；比如，忽略 Harness L2 层报出的“轻微架构违规”，选择“Override and Merge”。
这引出了一个至关重要的概念：Goldilocks 速度（刚刚好的速度）。它不是理论上的最快，也不是保守的最慢，而是那个能让整个系统——包括人、agent、Harness——都处于最佳协作状态的节奏。找到它，需要回答三个问题：
- What is the cost of being wrong?（犯错的代价是什么？）一个用于内部数据分析的脚本，犯错代价是重跑一次；一个处理支付的微服务，犯错代价是资金损失和声誉崩塌。前者可以接受更高的 autonomy，后者则必须维持严格的 human-in-the-loop。
- What is the cost of being slow?（变慢的代价是什么？）在一个需要快速迭代的 PoC 项目中，“慢”意味着失去市场机会；在一个维护了十年的核心交易系统中，“慢”意味着更稳健的演进。速度的价值，必须放在具体的业务语境中衡量。
- What is the cost of cognitive overload?（认知过载的代价是什么？）同时监控 5 个 agent 的会话、审查 3 个不同 subagents 的输出、在 10 个 Harness 报告中做决策……这种强度，远超人类的持续专注极限。其后果不是“慢”，而是“错”——漏掉一个关键的 L4 沙箱警告，或者误判一个 L2 的架构违规。
我们团队现在有一个“速度决策矩阵”，它不是一个冰冷的表格，而是一个活的、需要定期回顾的对话。每当引入一个新的 Coding Agent use case，我们都会坐在一起，用这三个问题进行辩论。这个过程本身，就是对团队 AI 素养的一次淬炼。
5.2 从“写代码”到“写 Harness”：工程师的新核心能力
范式转移的终极体现，是工程师核心能力的迁移。过去，一个 Senior Engineer 的价值，体现在他能写出多么优雅、高效、可维护的代码。今天，他的价值，越来越体现在他能设计出多么健壮、精准、可演化的 Harness。
这要求一种全新的混合能力：
- Deep Domain Knowledge：他必须比任何人都更清楚，这个业务领域的“正确”意味着什么。是数据一致性？是最终一致性？是严格的 ACID？这些抽象的业务规则，必须被翻译成 concrete 的 Harness 规则（如
@Transactional的传播行为、Saga 模式的补偿逻辑）。 - Systems Thinking：他需要像一个架构师一样，理解整个交付流水线。他知道，一个 L3 层的 E2E 测试失败，其根因可能在 L1 层的 context 描述不准确，也可能在 L2 层的架构规则过于宽松。他能看到各层之间的因果链。
- AI Literacy：他必须理解 LLM 的“脾气”。他知道，当 agent 在一个复杂的重构任务中反复失败时，问题很可能不是规则写错了，而是 context budget 不足，或者缺少一个关键的
codebase-explorersubagent 来提供全局视图。
这种能力的培养，无法通过阅读文档完成。它只能来自实战：亲手为一个新项目 scaffold Harness 模板，亲手调试一个在 L2 层反复失败的 ArchUnit 规则，亲手在 L4 沙箱中追踪一个神秘的network timeout。我们鼓励工程师将 20% 的工作时间，专门用于 Harness Engineering——不是为了交付功能，而是为了交付“交付功能的能力”。
5.3 信任的基石：不是“它不会错”，而是“错时我能知、能控、能修”
最后，也是最根本的一点：Coding Agent 范式所追求的，从来不是创造一个永不犯错的神。它追求的，是一种可计算、可干预、可修复的信任。
这种信任，建立在三个坚实的支点上：
- Visibility（可见性）：Harness 的每一层，都必须提供清晰、即时的反馈。当 L2 的 lint 失败时，它必须精确指出是哪一行代码、违反了哪一条规则、为什么这条规则如此重要。模糊的错误信息，是信任的最大敌人。
- Controllability（可控性）：在任何一个环节，人类都必须保留“紧急制动”的权力。无论是 L1 的输入过滤器，还是 L4 的沙箱执行，都必须有一个明确的、一键式的 bypass 机制（如
--forceflag），但这个机制的使用，必须被完整记录、审计，并触发一次事后 review。 - Repairability（可修复性）：Harness 的设计，必须天然支持“修复”。一个 L3 的 E2E 失败，不应该只是一个红色的 ❌，而应该是一个可点击的链接，点击后能自动打开一个 pre-filled 的 GitHub Issue，其中已经包含了失败的详细日志、相关的代码 diff、以及一个由 agent 建议的初步修复方案。
这才是范式转移的终点。我们不再问“AI 能不能写好代码”，而是问“当 AI 写出的代码需要被修复时，我的 Harness 能否让我在 5 分钟内定位、理解并完成修复？”当这个问题的答案是肯定的，那么，无论模型如何进化，无论范式如何转移，我们作为工程师，都将始终站在坚实的大地上。