文章主要基于最近很火 github.com/bojieli/ai-... 《深入理解 AI Agent》（作者和 Agent 合作完成的一本书）第一章和最近总结的 claude code 源码 分析的有感而写，前端失业转 Agent 开发中，有不对的地方感谢指出
Agent = 大模型 + 上下文 + 工具
那最近一直说的 Harness 又是什么？
通过 ReAct 循环很容易把 大模型 + 上下文 + 工具串起来，实现一个 Agent。
用户提出问题，模型先思考 当前应该做什么，然后调用工具行动，再观察工具返回的结果并继续思考下一步， 把整个过程的模型返回、工具执行结果这些上下文每次都带给模型，思考 -> 行动 -> 思考 -> 行动 ... ，直到完成任务。
把之前这篇文章 一文入门 Agent 的代码拿过来：
python
def solve(self, question: str, verbose: bool = True) -> str:
"""
使用 ReAct 模式解决问题
Args:
question: 用户问题
verbose: 是否显示详细过程
Returns:
最终答案
"""
messages = [
{"role": "system", "content": self._get_system_prompt()},
{"role": "user", "content": question}
]
for step in range(self.max_steps):
if verbose:
print(f"\\n=== 步骤 {step + 1} ===")
# 获取模型响应
try:
assistant_message = self._call_llm(messages)
if verbose:
print(f"Assistant: {assistant_message}")
messages.append({"role": "assistant", "content": assistant_message})
# 检查是否包含最终答案
if"Final Answer:"in assistant_message:
final_answer = assistant_message.split("Final Answer:")[-1].strip()
if verbose:
print(f"\\n🎉 找到答案: {final_answer}")
return final_answer
# 解析并执行行动
action_result = self._parse_action(assistant_message)
if action_result:
tool_name, params = action_result
observation = self._execute_tool(tool_name, params)
if verbose:
print(f"🔧 执行工具: {tool_name}")
print(f"📋 参数: {params}")
print(f"👁️ 观察结果: {observation}")
# 添加观察结果到对话历史
messages.append({
"role": "user",
"content": f"Observation: {observation}"
})
else:
# 如果没有找到有效的行动，继续下一轮
if verbose:
print("⚠️ 未找到有效的行动，继续思考...")
except Exception as e:
error_msg = f"API 调用错误: {str(e)}"
if verbose:
print(f"❌ {error_msg}")
return error_msg
return"达到最大步数限制，未能找到答案。"然后看似就实现了一个非常通用的问答 Agent
程序不再限制用户可以问什么类型的问题、问题格式是什么，使用什么工具、拿到结果下一步怎么做也不再写死逻辑到代码里，变成了大模型指挥一切。
程序好像一下子附上了魔法，但这算实现了 Agent，到此结束了吗？
一个能跑的 Demo 和一个可靠的产品之间还有巨大的鸿沟，而这些脆弱点正是 Harness 工程要解决的问题。
模型可能产生幻觉（编造不存在的工具或参数）、选错工具，或在遇到错误时无法自我恢复，生产系统还要加入约束、验证和纠正。
Harness 负责把模型放进一个可控的运行环境里：
- 给模型准备上下文：系统提示词 、工具定义、用户消息、模型回复、工具执行结果
- 暴露工具接口：搜索、读写文件、调用 API、执行代码等。
- 约束行为：哪些能做，哪些要用户确认，哪些绝对不能做。
- 验证结果：工具调用是否成功，产物是否满足要求，状态是否真的改变。
- 纠正失败：重试、回滚、换策略、熔断、交给人。
所以文章开头 「Agent = 大模型 + 上下文 + 工具」只是最小工程实现，一个真正能可靠做事的 Agent 应该是：
Agent = 大模型 + Harness
Harness = 上下文管理 + 工具接口 + 约束 + 验证 + 纠正
知道了 Harness 的概念，接下来就有另一个常常探讨的问题：如果模型持续变强，今天这些 Harness 会不会最终被模型「吃掉」？
模型可以通过后训练将工具调用能力内化为原生能力，慢慢的蚕食 Harness，公式未来可能再次简化为 Agent = 大模型，「模型即 Agent（Model as Agent）」。
比如 KimiK3 通过强化学习训练，将工具调用的决策策略内化为原生能力------何时调用工具、调用哪个、传什么参数都由模型自主决定，从而能够自主完成网络搜索等任务。
GPT-5.6 通过后训练将 Deep Research 式的任务编排策略内化为原生能力------何时澄清用户意图、何时搜索网络、何时调用代码解释器分析数据、何时继续补充信息，都由模型自主决定。
坏消息是节奏确实是这么个节奏，好消息是此刻还没有，这个「吃」的过程远比想象中慢。模型无法一次内化真实业务中所有的约束与偏好，模型此刻的能力边界，就是 Harness 此刻的价值所在。
模型自主决策的空间越大，出错时的影响面也越大，因此需要更精细的约束、验证和纠正机制来确保可靠性。模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层，转而兜底新的能力前沿。
继续，Harness 是最终答案了吗？
最早大家做 Prompt Engineering，重点是「怎么把一句话写好」，让模型回答得更准。
后来发现光写 prompt 不够，于是进入 Context Engineering ：不只是改一句提示词，而是管理模型能看到的全部信息，比如系统提示词、工具说明、历史对话、知识库、用户记忆。核心问题变成：模型该看到什么？
再往后是 Harness Engineering ：光让模型看到还不够，还要让它「可靠地行动」。所以要设计工具接口、权限约束、结果验证、错误恢复、反馈循环。核心问题变成：模型运行在什么样的工程外壳里？
然后是 Loop Engineering ：关注点从一次任务运行，扩展到长时间、多轮次的持续执行。比如 Agent 下一步该做什么、什么时候检查结果、什么时候才能真的停下来。核心问题变成：怎么让 Agent 持续推进任务，而不是中途偷懒、卡死或假装完成？
最后是 Graph Engineering ：把多个 Agent 循环、普通程序、人类审批步骤都组织成一个明确的执行图。哪个节点做什么，结果流向哪里，什么时候持久化状态，都由图结构管理。核心问题变成：怎么把多个能力单元编排成一个可控系统？
概念越来越多，也不用担心之前的段子「AI 领域只要学的慢就不用学了」，这些概念并不是跳变，而是后者包含前者，层层包含，核心是一个共同目标「设计一个可靠、可验证、可持续运行的 Agent 产品」。
Agent 岗位的出现，也正是因为当各家模型的能力越来越接近、不再是决定性的差异因素时，竞争优势就转移到了模型之外的工程实践。
而工程实践可能要考虑到一些东西：
-
选择模型：开源的、闭源的、多模态的、带推理的、成本、速度，要选最适合真实任务、预算、策略边界和交互形式的模型
-
编排模式：上下文如何在多次模型调用之间流动，工具如何被调度，执行路径是预先写死（工作流模式），还是由模型动态决定（自主 Agent 模式）。
-
安全性：降低提示注入、越权操作、隐私泄露、错误执行等问题。在信息进入上下文前过滤无关、有害或恶意内容；在工具调用或回复生效前检查权限、风险等级和输出内容，高风险操作可要求人工确认；通过数据库权限、行级安全、约束校验等机制阻止越权修改。
软件工程有设计模式，比如之前总结的前端设计模式 pattern.windliang.wang （时代的眼泪），Agent 工程当然也会发展出来：
- 提议者---审核者：生成和评判分离：一个角色产出，另一个独立角色只看结果、测试或结构化证据来判断，避免同一个 Agent 自审。
- 渐进式披露：不把所有信息一次性塞进上下文，而是先给目录，再按需加载细节，以节省上下文并提高选择精度。
- 只增不改：状态以追加方式演进，已经写下的内容不轻易改动，从而便于缓存、重放和审计。
- 边界集 + 保留集：每次修改同时验证「应该被改变的样本」和「不应该被影响的样本」，避免过拟合或无效修改。
- 最小 diff + 可回滚：每次改动尽量小、来源清楚、可以单独撤回，方便出问题时定位和恢复。
最后再来三个原则：
- 保持简单，从最直接的方案开始，只有确实需要时才增加框架和抽象，因为复杂度会增加调试盲区；
- 保持透明，让 Agent 的计划、执行日志和关键决策可观察，方便调试，也让用户知道系统为什么这样做；
- 设计好工具接口，从 Agent 的视角设计清晰、直观、不易误用的工具名称和参数，把错误尽量消除在接口设计阶段，而不是指望模型每次都猜对。
AI 时代的巨轮滚滚向前，前端经历了从切图仔、到从后端剥离为独立岗位、到欣欣向荣、到前端已死、再到现在的合并回后端岗位，和后端一起又回到了全栈岗位。
好消息是当然也带来了新的岗位「Agent 开发」，像之前所说的，工具在变，但核心还是解决问题。过去的积累也不是全部没用了，做工程化的东西很多东西都还在（处理状态、接入接口、权限控制、记录日志、做监控、优化体验等等），只是多在程序中引入了一个大脑，而且很多东西还可以和 AI 探讨、让 AI 实现。
当选择了程序员的道路，就代表拥抱了终身学习，加油、共勉。