技术博客 | 记录学习笔记和思考

LLM 只做一件事：给定输入，生成输出。

模型是固定的。你能控制的，其实只有输入，以及围绕输入输出构建的系统。

由此派生出两个真实的工程问题域。

问题域 A：如何构造更好的输入

这是一个连续的复杂度谱系：

• 手工写指令 -> Prompt Engineering
• 动态检索、拼装、压缩信息 -> Context Engineering

两者解决的是同一类问题，只是复杂度不同。

Context Engineering 本质上是 Prompt Engineering 在系统规模下的自然延伸。它们是同一问题域上复杂度递增的连续谱系，不是独立的新范式。

问题域 B：如何让围绕模型的系统可靠运行

执行控制、测试评估、监控、改进闭环，这才是真正不同的问题域。

它和输入构造无关，是围绕模型系统化运行时新增出来的工程复杂度。

更清晰的结构

1
2
3
4
5
6
7
8
9

LLM 工程
│
├── 输入构造（A）
│   └── Prompt Engineering -> Context Engineering
│       （同一问题域，复杂度递增）
│
└── 系统可靠性（B）
    └── Execution / Eval / Observability / Feedback
        （不同问题域，真正的新增复杂度）

Harness Engineering = A + B，不是独立的新范式。

结论也就很清楚：

• Prompt Engineering 和 Context Engineering：程度差异，不是本质差异
• Harness 的工程基础设施层：才是真正不同的问题域
• 把三者并列称为独立范式：是一种概念通货膨胀，反而掩盖了真实的工程结构

MCP 更像是一份“平台能力说明书”。

它定义了有哪些工具、怎么调用、权限边界在哪。

Skill 则是在回答另一类问题：具体怎么把事做完。它本质上是 prompt 加上工具使用策略的封装。

Skill 之所以更好用，是因为关键步骤、调用方式、甚至容错逻辑，都已经被提前写进去了。这本来就不是 MCP 要解决的问题。

至于说 CLI 会不会替代 MCP，我更倾向于把它看成两类场景在分化。

CLI 在本地自动化、单用户环境下确实更直接高效；但一旦涉及权限、审计、跨系统协作，MCP 这类协议层仍然有不可忽视的优势。

长期看，也许会出现更适合 Agent 的新接口形态。

但至少在现在，CLI、MCP、Skill 更像是在协同演进，而不是简单地相互取代。

大多数 AI 系统还停留在“单次推理”形态。

任务来了重新规划，执行完毕即丢弃，成功经验从不沉淀。

真正面向长期运行的架构，得把“执行路径”变成资产。

核心是三层分离：

• 方法层：定义目标和策略
• 执行层：保存经过验证、可运行的代码或 Script
• 评估层：检测退化并触发修复

某条路径反复验证稳定后，就应该固化成 Script，后续默认走它。推理只在出问题时再介入。

这里有个值得关注的认知转变：

AI 时代真正需要长期打磨的“代码”，往往不是传统代码本身，而是 prompt、skill、方法描述这些东西。

传统代码反而更像执行介质，可以在策略约束下被持续生成、替换、修复。

维护重心也因此上移了。

过去是在“雕刻代码”，现在更像是在持续优化目标、约束与成功标准的表达方式。

系统不再是每次重新解题，而是在时间维度上真正积累能力。