虽然人类不需要经常亲自手写代码，但软件工程的工作并没有消失。而是完全演变成了不同的形态，如今软件工程师的核心职责变了，变成为 Agent 搭建稳定可靠的系统与支撑框架，以此来尽可能地提高代码产出效率。

不管是 Prompt Engineer、Context Engineer、Harness Engineer，这些都不是噱头、也不是终局，是 AI 进化的过渡期的关键技术。

Prompt Engineer (提示工程)

关注点：“怎么问问题”。即通过设计和优化输入给 LLM 的自然语言指令，引导模型输出预期的结果。
在 Agent Engineering 中的定位：与大模型交互的最基础层面。主要用于定义 Agent 的“人设”、核心行为准则以及输出规范（例如要求输出严格的 JSON 格式）。它高度依赖于模型本身的预训练知识和内在推理能力。
关键技术：
- 少样本提示（Few-shot prompting）
- 思维链（Chain of Thought, CoT）
- 角色扮演（Role-playing）
- 特定格式的提示词模板（如 ReAct 模板）。

Context Engineer (上下文工程)

关注点：“怎么给信息”。可以理解成：设计、选择、组织、压缩、加载、更新、验证模型在推理时看到的上下文。它比 Prompt Engineering 更大，不只是“怎么写提示词”，而是“什么时候给模型什么信息、以什么结构给、给多少、怎么避免噪音”。Anthropic 也把 context engineering 视为 prompt engineering 的自然演进，重点是让 agent 更可控、更有效。🌐 Anthropic
在 Agent Engineering 中的定位：解决大模型的“幻觉”和知识时效性问题。对于一个有状态的 Agent 而言，如何优雅地管理历史会话、提取核心事实并与外部知识库结合，是 Context Engineering 的核心挑战。它相当于把 LLM 从一个“仅靠常识答题”的考生，变成了“带着精准复习资料开卷考试”的学霸。
关键技术：
- 渐进式披露（Progressive Disclosure）：控制信息加载时机：先给最小必要上下文，需要时再展开；
- RAG：上下文获取/检索层：从外部知识库动态取证据，检索优化；
- Skill：可复用的上下文包 + 工具/流程/代码能力，按需加载；
- Prompt 模板：静态上下文结构设计；
- Memory：跨轮次、跨任务的长期/短期上下文管理（多级记忆架构，记忆系统的状态管理与垃圾回收；
- Tool / MCP：让模型通过工具获取或修改上下文；
- 上下文压缩（Context Compression）：压缩、摘要、去噪、重排上下文；
- Context Evaluation：评估给进去的上下文是否足够、相关、可追踪。

Harness Engineer (治理/编排工程)

关注点：“怎么搭系统”。即构建包裹 LLM 的外部系统设施（Harness 本意为挽具、安全带），使其成为一个可控、可评估、可落地的软件工程系统。 Agent = Model + Harness 🌐 harness-engineering | OpenAI 🌐 effective-harnesses-for-long-running-agents | Anthropic 🌐 harness-design-long-running-apps | Anthropic
在 Agent Engineering 中的定位：这是真正将大模型落地为工程级 Agent 的关键。它负责给大模型“装上手脚”（执行工具），构建“感知-思考-行动”的闭环，并确保整个系统在复杂业务环境下的稳定性、容错性和安全性。
关键技术：
- 工作流编排（如状态机设计、DAG 执行流）
- 工具调用与执行引擎（Tool/API Calling）
- 安全护栏（Guardrails，用于输入输出的合规校验）
- 多 Agent 协作路由（Router）
- 系统评估框架（Eval）。
Harness 架构
1. Solo Harness：Generator
2. Full Harness：Planner、Generator、Evaluator

Ref

工程化

复杂 Agent 框架 or Harness Engineer ？

两者对比

复杂 agent 框架可以是 Harness Engineering 的一部分，但 Harness Engineering 不等于复杂 agent 框架。 更准确地说：Agent 框架偏“结构与编排”，Harness Engineering 偏“让 agent 在真实环境里可靠运行”。

层级	关注点	例子
Agent Framework	agent 怎么组织、怎么协作	planner/executor、multi-agent、workflow graph、role agents
Harness	agent 怎么被安全、稳定、可观测地运行	tool 调用、权限、状态、日志、eval、重试、回滚、sandbox、trace
Context Engineering	agent 看什么、什么时候看、看多少	RAG、memory、渐进式披露、summary、context budget
Product Workflow	agent 解决什么业务问题	写代码、处理客服、做研究、生成报告、跑数据分析

所以，一个复杂 agent 框架里面可能包含 harness，例如：

Agent Framework
├── Planner
├── Executor
├── Tool Router
├── Memory Manager
├── Multi-agent Coordinator
├── State Machine
├── Eval Harness (Harness)
├── Trace Logger (Harness)
├── Permission Layer (Harness)
└── Recovery / Retry System (Harness)

下面这些，更像 Harness Engineering：

Eval Harness
Trace Logger
Permission Layer
Recovery / Retry System
Tool Execution Runtime
State / Checkpoint
Sandbox

而这些，更像 Agent Framework：

Planner
Executor
Multi-agent Coordinator
Role Agents
Workflow Graph

区别在于：是在设计 agent 的“脑内组织结构”，还是在设计 agent 的“外部运行保障系统”。

比如 Agent Framework 像机器人身体结构：

几只手？
谁负责看？
谁负责想？
谁负责执行？
多个机器人怎么协作？

Harness 像实验室、工厂和安全系统：

工具能不能被正确调用？
错了怎么发现？
失败怎么重试？
有危险操作怎么拦截？
每一步有没有记录？
能不能复现一次失败？
能不能比较版本 A 和版本 B 哪个更好？

“复杂 agent 框架不就是 Harness Engineering 吗”，这个理解有一半是对的：当你的 agent 框架开始包含运行时、工具、安全、评测、日志、状态、回滚，它就已经在做 Harness Engineering 了。但两者的重心不同。

判断标准

主要在解决什么问题：

如果是解决 “agent 怎么分工、怎么规划、怎么循环、怎么协作？” -> Agent Framework
如果是解决“agent 怎么稳定、安全、可评测、可复现、可上线？” -> Harness Engineering

为什么不建议一开始做“复杂 agent 框架”

不是因为 harness 不重要，而是因为很多人一开始说“我要做 agent 框架”，实际会优先做这些东西：

多 agent role play
planner / executor
graph workflow
memory graph
task decomposition
自定义 DSL
各种抽象层

往往容易忽略真正有用的 harness：

eval 数据集
regression test
trace viewer
tool call replay
sandbox
permission boundary
failure taxonomy
checkpoint / resume
human approval
output verifier

结果就是框架很复杂，但 agent 还是不稳定。

Harness Engineer 要深入到什么程度？

不需要把它当成一个独立技术路线死磕，但要掌握它的工程思维。至少应该会做这些东西：

能力	价值
Agent 运行循环	理解模型、工具、状态如何互动
Tool schema 设计	决定模型能不能可靠调用工具
Context 管理	决定模型是否看见正确资料
Eval harness	决定你能不能知道 agent 变好还是变差
Trace / logging	决定失败后能不能定位问题
Guardrails / permission	决定能不能安全上线
Retry / rollback / checkpoint	决定长任务能不能跑完
Sandbox / filesystem / browser / shell	决定 agent 能不能真正执行任务

这比单纯会 LangGraph、AutoGen、CrewAI 更重要。框架会变，但这些底层问题不会变。

什么时候需要复杂 agent 框架？

只有在下面情况才值得做复杂框架：已经有稳定的单 agent 工作流，并且遇到了明确瓶颈，比如：

单 agent 上下文太大，需要分工；
任务天然是并行的，比如研究、代码审查、测试生成；
需要可审计的多阶段流程；
需要长期状态、权限隔离和人工审批；
有多个工具系统要统一调度；
已经有 eval 数据，能证明复杂化提升了成功率。

否则，复杂 agent 框架往往会带来：

调试困难；
错误传播；
token 成本升高；
成功率不一定提升；
编排逻辑比任务本身还复杂；
最后变成“框架驱动开发”，而不是“问题驱动开发”。

开发路线

第一阶段：Context Engineering

渐进式披露
RAG
Memory
Prompt routing
Summarization / compression
Context window budgeting
Skill / tool description

目标：让模型“看见该看的东西”。

第二阶段：Eval Harness

先不要做复杂 agent。先做一个测试台：

固定任务集
固定输入
期望输出
自动评分
trace 记录
regression test
cost / latency / success rate 统计

这一步非常关键。没有 eval，做 agent 框架基本是在凭感觉。

第三阶段：Runtime Harness

做一个最小 agent 运行环境：

tool registry
tool permission
execution log
retry policy
state store
checkpoints
human approval
error recovery

目标：让 agent 不是“会回答”，而是“能可靠执行”。

第四阶段：再抽象成框架

当你重复写了 3 次类似逻辑，再抽象：

planner
executor
verifier
memory manager
tool router
policy engine
workflow graph

不要先造框架，再找需求。应该先解决任务，再抽象框架。

深入 Harness Engineering 的思想和关键模块，但不要急着造复杂 agent 框架。先做能评测、能复现、能失败恢复的“小而硬”的 agent 系统。

真正厉害的 agent 工程不是多 agent、多框架、多流程图，而是：每次失败都能被记录、解释、修复，并沉淀到 harness 里。

结论

Harness Engineering 是复杂 agent 框架中最值得优先建设的那一部分。不是所有 agent 框架都是好 harness，但好的生产级 agent 框架一定包含强 harness。

复杂 agent 框架更偏“结构与编排”，而 Harness Engineering 更偏“让 agent 在真实环境里安全、稳定、可观测地运行”。两者会重叠，但 Harness 是更底层、更工程化、更接近生产落地的核心。

开发顺序应该是：

Context Engineering
	   ↓
Tool Runtime
	   ↓
Eval / Trace / Replay
	   ↓
Permission / Sandbox / Recovery
	   ↓
Minimal Agent Framework (Planner / Multi-agent / Graph Framework)

而不是：一开始就做复杂多 agent 框架、DAG 编排、planner/executor、memory graph、工作流引擎。复杂 agent 框架容易变成“架构很漂亮，但实际成功率不高”。真正决定 agent 能不能长期稳定工作的，通常是：

任务边界清楚
上下文喂得准
工具设计得好
每步有验证
失败能恢复
可观测、可复现、可评测
权限和状态受控

这些正是 Harness Engineering 的核心。

Agent Engineering