很多人在 2026 年还会把“AI 学习助手”理解成一个聊天机器人——用户提问，模型回答，最多套一层提示词。如果只是这样，模型的能力上限基本已经到头了。我们真正需要的学习助手，不是一个“会说话的百科全书”，而是一个能记住你学过的知识、发现你重复犯错、并且能用不同方式重新教你一遍的个性化 Agent。
但要做到这一步，光靠“换更好的 Prompt”“换更大的模型”是远远不够的。真正决定一个 Agent 是“可控的生产工具”还是“随时跑偏的玩具”的，是它外面那层引擎——也就是 Harness，中文社区通常翻译成“驾驭工程”或“闸道工程”。它管住了模型能看什么、能做什么、不能做什么，同时承接上下文工程和反馈闭环。这篇文章会用一个“编程学习助手”的开发案例，把 Harness、上下文工程、自我进化 Agent 这三件事串起来讲清楚。
先把一个核心判断放在前面：2026 年的 AI 应用开发，竞争焦点已经从“选哪个模型”迁移到“怎么驾驭模型”。模型能力差距在缩小，工程层的差距在拉大。对一个学习助手来说尤其如此——同样的模型，有人能让它因材施教，有人只能让它输出干巴巴的百科文本，差别几乎全在 Harness 和上下文设计上。读完全文，你会知道如何设计一个带约束、带记忆、能调整策略的 Agent，也能把它套用到问答助手、编程陪练、知识库搜索等其他场景。
1. 为什么要做“学习助手开发”这个案例？
先说为什么选学习助手。它看起来简单，实际是整个 AI Agent 工程能力的一个“微缩战场”。
普通聊天机器人只需要“用户问 - 模型答”一个回合，这几乎不需要状态管理。学习助手不一样：用户今天学 Python 基础，明天学异常处理，后天可能又把基础忘了。你要让模型知道昨天发生了什么，还要让它根据用户的答题表现决定今天先讲哪个概念。这背后涉及状态管理、记忆存储、策略调整、内容检索，几乎把 Agent 开发的关键问题全部覆盖了。
另一个原因是学习助手的反馈信号非常密集。用户说“没听懂”、答错了一道题、主动要求换个讲法，这些都是天然的标注数据。没有反馈，Agent 就谈不上“自我进化”；有了反馈而不知道怎么利用，Agent 就只是披着进化外衣的静态系统。学习助手是把反馈闭环做得最自然的领域之一，很适合作为理解“自我进化 Agent”的入门项目。
从工程可行性的角度看，学习助手的需求边界也足够清晰。它不需要调用真实世界的物理接口，不需要处理高风险支付操作，所有功能都可以在“文本输入输出 + 检索 + 存储”范围内实现。这意味着我们可以把注意力集中在 Harness 和上下文设计本身，而不是被外部系统对接拖住。
所以，本文的案例边界是这样定义的：一个面向零基础编程学习者的一对一教学 Agent。它能讲解概念、出题测试、分析答错原因，并在一段时间的使用后，根据学习数据调整讲解风格和教学顺序。它解决的核心问题是：如何让同一个大模型，对不同的人展现出不同的教学策略，并长期维持这种一致性。
2. 三个关键概念：Harness、上下文工程、自我进化 Agent
2.1 什么是 Harness（驾驭工程）
Harness 在硬件领域的意思是“线束”或“测试夹具”，在 AI Agent 语境下，它指的是“包裹在模型之外的运行时控制层”。通俗地讲，大模型是一个执行力很强但方向感不稳定的员工，你需要给它搭一个清晰的作业台——上面放什么资料、给哪些工具、按什么流程走、哪些动作禁止，这个作业台就是 Harness。
从技术实现上看，Harness 至少包含以下能力。
第一，工具调度。模型不直接执行代码或查数据库，而是“提出工具调用请求”，让 Harness 去执行并返回结果。这样工具权限可以被集中控制，模型不会越过边界直接接触外部系统。
第二，状态流转。Agent 不能每一轮都像第一次见面那样思考，Harness 需要维护会话状态和任务阶段，比如“当前是在讲解、还是在出题、还是在等待答题结果”。
第三，约束注入。模型输出不能是自由的文本，Harness 会要求模型按 JSON 或结构化格式输出，并做合法性校验。对学习助手来说，这意味着模型必须按“知识点 + 示例 + 小结”的结构输出，而不是随意发挥。
第四，安全护栏。包括内容过滤、超时控制、上下文长度保护等，防止模型在长对话中“失控”。
这里有一个常见的误解：很多人认为 Harness 就是把几个 API 调用拼在一起，或者只是简单的函数封装。实际上，Harness 的核心是“决策权归属”。在传统的软件编排里，流程是代码写死的；在 Harness 工程里，流程的一部分由模型决定，Harness 负责决定“模型有多少决策权、能在哪些选项里选”。这个权力边界的设计，才是驾驭工程真正难的地方。
2025 年下半年到 2026 年，社区关于“DeepSeek Harness”“模型与 Harness 结合”的讨论明显增多，核心背景是开源模型的能力越来越接近闭源模型，而部署方式也更灵活。这时“怎么用”比“用哪个”更重要，Harness 工程的价值也因此被放大。从项目实践看，与其纠结模型参数，不如先把 Harness 做扎实——它是当前性价比最高的工程投入。
2.2 什么是上下文工程
上下文工程（Context Engineering）是指围绕大模型上下文构建、管理和优化的一整套技术。它回答的问题是：模型每次调用时，应该看到哪些信息？以什么顺序？以什么形式？
很多开发者对上下文工程的理解停留在“提示词写得好一点”。提示词确实是其中一部分，但上下文工程的内容远不止这些。它至少包括四个层面。
系统提示：描述 Agent 的角色、行为约束、输出格式、语气风格。这是最基本的上下文，也是 Harness 里最容易调整的部分。
事实检索：当用户问到知识库里的内容时，上下文工程负责把最相关的文档片段检索出来，在调用模型之前拼接到上下文中。这一层通常结合向量检索和 BM25 等传统检索技术。
对话记忆：把历史对话整理成结构化的摘要或关键状态，而不是把所有原始消息都塞给模型。上下文窗口是有限的，记忆管理决定了模型“记得”多少真正有用的信息。
工具说明：模型需要知道有哪些工具、每个工具的作用和参数限制，才能正确发出工具调用请求。工具说明写得好不好，直接决定模型调用工具的准确率。
上下文工程的重要性，在 2026 年比在 2023 年反而更高，原因是模型上下文窗口越做越大，开发者开始“懒得管理”上下文，什么东西都往里塞。结果就是 Token 成本上升、响应变慢、关键信息被淹没。上下文工程的核心不是“放更多”，而是“精准地放”。对学习助手来说，这一点尤其致命——一个用户画像被淹没在 5 万 Token 历史记录里的教学助手，和没有画像没有任何区别。
2.3 什么是自我进化的 Agent
“自我进化的 Agent”这个词容易被理解成 AGI 式的自主成长，好像模型会自动变得无所不能。从工程角度看，更准确的理解是：Agent 系统通过反馈闭环，持续改进自己的行为策略，而不是每次对话都从零开始。
具体到实现，自我进化体现在三个层面。
记忆更新：每次交互结束后，Agent 把新信息写入持久化存储，比如用户对某个知识点的掌握度、偏好的讲解风格、最近犯过的错误类型。
策略调整：Agent 根据记忆里的统计结果，动态调整后续的系统提示。例如用户连续三次答错“递归”，讲解策略就从“直接讲定义”切换为“先讲函数调用栈”。
工具优化：Agent 或开发者可以根据工具的使用反馈，调整工具的描述、参数，甚至淘汰掉长期不被有效使用的工具。这一层在成熟系统里往往由评测驱动。
值得注意的是，自我进化并不等于“让模型写自己的提示词”。更稳妥的做法是建立清晰的评估指标，让系统根据指标调整可配置的策略参数。学习助手里最核心的指标是“学生对同一个知识点的复测正确率”，这个指标直接决定系统是否要更换讲解策略。
同样，自我进化也不意味着不可控。每一次策略变更都应该有记录、可回滚。一个生产环境可用的进化 Agent，必须有“进化日志”和“版本控制”，否则系统会在几次糟糕的更新后进入不可恢复的混乱状态。这一点在后面的最佳实践里会重点展开。
3. 项目需求分析与整体架构设计
3.1 功能需求分析
我们把这个学习助手拆成四个核心功能模块。
知识点讲解：用户提出一个主题，助手以教学风格给出讲解，同时检查用户的基础水平，避免概念跳跃。
主动出题测试：讲解结束后，助手出一道针对性的判断题或选择题，用来验证用户是否理解。题目的难度根据用户历史正确率动态调整。
答题结果分析与反馈：用户答错时，助手要定位错误类型——是概念混淆、记忆遗忘，还是完全没看懂——并给出不同的解释路径。
个性化策略更新：每次会话结束后，系统更新用户画像字段，包括掌握度、错误类型分布、偏好风格。用户画像会影响下一轮系统提示的构建。
这些需求中，前三个可以通过“Harness + 上下文工程”实现，第四个则依赖自我进化机制。它们是分层关系，不是并列关系。
3.2 非功能需求与约束
除了功能，项目还要满足几个工程层面的约束。
可控性：模型输出必须经过 Harness 校验，不能出现与教学主题无关的任意发挥。
可解释性：每次教学策略的调整，都要能追溯到具体的统计数据，不能是“模型凭感觉”。
可扩展性：新增一个教学工具（比如加一个“出代码题”的工具），不应该改动核心流程代码。
成本可控：单次教学会话需要控制上下文长度，避免无意义的 Token 消耗。
这些约束直接决定了架构设计。为了满足可扩展性，我们采用“工具注册 + 状态机 + Harness 调度”的模式；为了满足可解释性，我们用持久化的统计数据驱动策略，而不是让模型自我修改 Prompt。
3.3 整体架构
项目采用模块化设计，核心是 Harness 引擎，它连接四个部分：上下文管理器、工具执行器、演化引擎和记忆存储。
learning_harness/ ├── config/ │ └── harness_config.yaml ├── core/ │ ├── harness.py │ ├── context.py │ ├── state_machine.py │ └── tools.py ├── memory/ │ ├── profile_store.py │ └── feedback_store.py ├── eval/ │ └── mastery.py ├── main.py └── requirements.txtHarness 引擎是运行时的中枢。它读取状态机的当前状态，决定下一步可以让模型执行哪些工具；模型返回工具调用请求后，Harness 调用对应工具，把结果拼回上下文，再进入下一轮模型调用。
上下文管理器负责动态构建模型调用时的 system prompt 和 user prompt。它从记忆存储读取用户画像和学习状态，从知识库检索相关资料，再拼接成本次调用的完整上下文。
演化引擎不是运行时路径的一部分，它是在会话结束后异步执行的。它读取本次会话的反馈记录，更新用户画像，并决定是否需要切换教学策略。
这个架构把“运行时”和“进化”分开，避免了自我进化逻辑阻塞交互响应，也让系统更容易测试和回滚。
4. 环境准备与项目初始化
4.1 运行环境与依赖
本项目的示例代码基于 Python 3.10 以上版本开发。模型接入部分使用 OpenAI 兼容的 API 格式，因此可以适配多种模型服务，包括各类支持 OpenAI 协议的本地或云端模型。具体模型版本以你实际使用的服务为准，本文不绑定某一个固定模型。
需要安装的依赖如下：
pip install fastapi uvicorn openai pydantic pyyaml如果你计划使用向量检索做知识库，可以再安装：
pip install sentence-transformers这里提醒一点：不要在项目里硬编码模型名称。把模型标识、API 地址、温度等参数统一放到配置文件里，方便迁移和对比测试。
4.2 配置文件设计
在config/harness_config.yaml中定义 Harness 的核心参数：
# config/harness_config.yaml model: name: "your-model-name" temperature: 0.3 max_tokens: 1024 harness: max_tool_calls_per_turn: 3 max_context_tokens: 8000 enforce_json_output: true memory: storage_path: "./data/profiles" feedback_limit: 200 evolution: update_enabled: true baseline_mastery: 0.6 retry_threshold: 3这些参数的含义分别是：
model.temperature：生成多样性控制，教学场景建议取 0.3 左右，保证稳定。harness.max_context_tokens：单次调用的上下文上限，防止长对话导致成本失控。harness.max_tool_calls_per_turn：每个回合最多允许模型调用多少次工具，避免模型陷入“反复查资料但不回答”的循环。evolution.retry_threshold：同一个知识点连续答错多少次后触发策略调整。
4.3 目录初始化
创建数据目录，用于存放用户画像和反馈记录：
mkdir -p data/profiles到这里，项目骨架就搭好了。下一节开始写最核心的 Harness 代码。
5. Harness 核心机制实现
5.1 状态机：把教学流程变成可控状态
学习助手每一轮交互不是一个孤立的问答，而是一个有阶段的流程。我们用状态机来定义流程，这也是 Harness 里最容易见效的设计。
教学流程分为四个状态：
INTRO：开始讲解新概念。QUIZ：出一道题测试用户理解。ANALYZE：分析答题结果。NEXT：根据结果决定进入下一个概念还是重新讲解。
状态之间的转移规则写在core/state_machine.py里：
# core/state_machine.py from enum import Enum class TeachState(str, Enum): INTRO = "INTRO" QUIZ = "QUIZ" ANALYZE = "ANALYZE" NEXT = "NEXT" class TeachStateMachine: def __init__(self, initial_state: TeachState = TeachState.INTRO): self.state = initial_state def transition(self, event: str) -> TeachState: if self.state == TeachState.INTRO: if event == "explain_done": self.state = TeachState.QUIZ elif self.state == TeachState.QUIZ: if event in ("answer_correct", "answer_wrong"): self.state = TeachState.ANALYZE elif self.state == TeachState.ANALYZE: if event == "analyze_done": self.state = TeachState.NEXT elif self.state == TeachState.NEXT: if event == "next_topic": self.state = TeachState.INTRO elif event == "retry_topic": self.state = TeachState.INTRO return self.state这段代码的核心意图是：模型可以在流程的“内容环节”自由发挥，但流程推进必须通过明确定义的事件。这比让模型自己决定“下一步该出题还是该讲解”要可靠得多。驾驭工程不是在每一步都限制模型，而是在“什么可以自由、什么必须按规则”之间划出清晰的线。
5.2 工具注册：把能力外置给 Harness
为了让 Harness 能调度工具，我们采用注册表模式。每个工具实现统一的接口，包含名称、描述和 execute 方法。工具描述会被拼接到模型上下文中，因此描述质量直接影响模型调用的准确率。
# core/tools.py from typing import Dict, Any class BaseTool: name: str = "" description: str = "" def execute(self, args: Dict[str, Any], ctx: Dict[str, Any]) -> Dict[str, Any]: raise NotImplementedError class ToolRegistry: _tools: Dict[str, BaseTool] = {} @classmethod def add(cls, tool: BaseTool) -> None: cls._tools[tool.name] = tool @classmethod def get(cls, name: str) -> BaseTool | None: return cls._tools.get(name) @classmethod def all_descriptions(cls) -> str: lines = [] for name, tool in cls._tools.items(): lines.append(f"- {name}: {tool.description}") return "\n".join(lines)实际注册时，每个工具的名称要短、语义要清楚，description 要写出“在什么场景下用”“参数有哪些”。例如：
class SearchKnowledgeTool(BaseTool): name = "search_knowledge" description = ( "当用户正在学习某个编程概念，且 Harness 判定需要补充知识库内容时使用。" "参数：query (str)，用户当前的问题或主题。" ) def execute(self, args: Dict[str, Any], ctx: Dict[str, Any]) -> Dict[str, Any]: query = args["query"] results = ctx["knowledge_base"].search(query, top_k=3) return {"documents": results} ToolRegistry.add(SearchKnowledgeTool())在实际项目中，工具描述会被插入到系统提示的工具区。好的工具描述应该像“接口文档”而不是散文：说明使用场景、参数、返回值，必要时给一个小示例。模型在生成工具调用时会参考这些描述，因此描述写得越准确，模型跑偏的概率越低。
5.3 Harness 主循环：模型与工具之间的调度中枢
Harness 主循环的核心逻辑是：接收用户输入 → 构造上下文 → 调用模型 → 判断结果是“最终答复”还是“工具调用请求” → 如果是工具调用，执行工具并把结果写回上下文 → 再次调用模型。
# core/harness.py from typing import Dict, Any class Harness: def __init__(self, model_client, context_builder, registry): self.model = model_client self.context_builder = context_builder self.registry = registry self.max_tool_calls = 3 def run_turn(self, user_input: str, state: Dict[str, Any]) -> Dict[str, Any]: # 1. 构建上下文 messages = self.context_builder.build(user_input, state) # 2. 模型在受限范围内决策 for _ in range(self.max_tool_calls): response = self.model.chat(messages) if response.is_tool_call: # 3. 执行工具调用 tool_name = response.tool_call.name tool = self.registry.get(tool_name) if not tool: return {"reply": f"未知工具：{tool_name}", "state": state} result = tool.execute(response.t
