实践在前，命名在后

“实践在前，命名在后”是什么意思？

• 命题: 概念的形成，是对大量实践经验的归纳，而不是实践的起点;
• 现象: 业界后来广泛使用 Skill、harness、loop engineering 等术语，但相应的工程实践往往更早出现;
• 推论: 当一个术语成为行业共识时，其对应的问题往往已经在领先系统中经过了长期探索;
• 对企业的含义: 实践不能始终滞后于概念的普及，否则只能在术语流行后才开始解决早已存在的问题;
• 位置: 这是引言给出的时间关系判断，也解释了为何本书讨论的原则能在术语更替后继续成立，见全书知识框架与阅读路径;

Pine 的实践早于哪些术语？

后来的术语	更早的实践	解决的问题
上下文工程 / 提示词管理	动态加载提示词	提示词无限膨胀
工具接口设计	命令行执行工具	工具列表无限膨胀
Agent 状态栏	系统状态栏技术	Agent 不感知执行环境、用户时间与工作状态
harness	类 Claude Code 的调用与兜底层	工具调用不稳定、幻觉、执行危险或越权操作、不遵循指令
loop engineering	提议者-审核者（proposer-reviewer）	模型过早认为任务已经完成

• 动态加载与状态栏的完整机制见第二章；Harness 的治理层定义见Harness 工程;

为什么不同团队会独立形成相近的方法？

• 现象: 这些方法并非 Pine 所独有，许多模型与 Agent 团队在解决相似问题时独立形成了相近的工程方法;
• 解释: 趋同说明它们反映的是 Agent 系统的共性约束，而非某家产品或某个模型的偶然选择;
• 来源场景: 书中原则主要来自长流程、高风险场景中的工程实践;
• 具体业务: Pine 让 Agent 代表用户与真人沟通，处理账单协商、退款投诉、订阅取消等涉及真实经济利益的任务;
• 任务特征: 跨越较长时间、包含多轮交涉，且单个步骤的错误就可能造成实际损失;
• 驱动力: 对可靠性、安全性、可审计性的严格要求，促成了书中强调的架构原则;

为什么必须选对能力上限要求足够高的真实业务？

• 条件一: 选择对 Agent 能力上限提出足够高要求的真实业务，并持续获取真实反馈;
• 机制: 足够复杂的场景会持续暴露模型能力与业务要求之间的差距，从而促使团队构建 Harness，系统解决模型暂时无法独立处理、业务却必须完成的问题;
• 反例: 如果业务需求很容易被下一次模型升级覆盖，团队较难积累稳定的系统设计原则;
• 压力示例: 一项任务可能持续数小时乃至数周，需要与多个利益相关方反复沟通，完成长时间通话、复杂表单操作和多轮邮件往来;
• 附带要求: 关键数字必须准确、操作必须可控，并始终维护用户利益;

为什么没有评估就无法判断改动是否有效？

• 条件二: 建立系统的评估（Evaluation）机制;
• 原因: 没有评估，就无法判断一次改动带来的提升究竟源于设计本身，还是仅仅来自随机波动;
• 作用: 评估把 Agent 的迭代从经验判断转化为可比较、可复现的工程过程;
• 地位: 这是以科学方法开展系统开发的基础;
• 展开位置: 评估方法论见第七章;

哪些东西能穿越模型的迭代周期？

• 观察: 几乎所有的成功 Agent 系统都遵循着相同的架构模式，这并非巧合;
• 判断: 好的设计原则本就应该穿越模型的迭代周期;
• 原因: 它们描述的不是某个模型的用法，而是智能系统与世界交互的基本模式;
• 三条不变的问题: “看到什么、能做什么、如何验证做得对不对”不会随 API、产品与榜单翻篇;
• 实用收益: 掌握了它们，任何下一代模型带来的新能力都能被放进核心公式的对应位置;