很多人在 2026 年还会把“AI 学习助手”理解成一个聊天机器人——用户提问模型回答最多套一层提示词。如果只是这样模型的能力上限基本已经到头了。我们真正需要的学习助手不是一个“会说话的百科全书”而是一个能记住你学过的知识、发现你重复犯错、并且能用不同方式重新教你一遍的个性化 Agent。但要做到这一步光靠“换更好的 Prompt”“换更大的模型”是远远不够的。真正决定一个 Agent 是“可控的生产工具”还是“随时跑偏的玩具”的是它外面那层引擎——也就是 Harness中文社区通常翻译成“驾驭工程”或“闸道工程”。它管住了模型能看什么、能做什么、不能做什么同时承接上下文工程和反馈闭环。这篇文章会用一个“编程学习助手”的开发案例把 Harness、上下文工程、自我进化 Agent 这三件事串起来讲清楚。先把一个核心判断放在前面2026 年的 AI 应用开发竞争焦点已经从“选哪个模型”迁移到“怎么驾驭模型”。模型能力差距在缩小工程层的差距在拉大。对一个学习助手来说尤其如此——同样的模型有人能让它因材施教有人只能让它输出干巴巴的百科文本差别几乎全在 Harness 和上下文设计上。读完全文你会知道如何设计一个带约束、带记忆、能调整策略的 Agent也能把它套用到问答助手、编程陪练、知识库搜索等其他场景。1. 为什么要做“学习助手开发”这个案例先说为什么选学习助手。它看起来简单实际是整个 AI Agent 工程能力的一个“微缩战场”。普通聊天机器人只需要“用户问 - 模型答”一个回合这几乎不需要状态管理。学习助手不一样用户今天学 Python 基础明天学异常处理后天可能又把基础忘了。你要让模型知道昨天发生了什么还要让它根据用户的答题表现决定今天先讲哪个概念。这背后涉及状态管理、记忆存储、策略调整、内容检索几乎把 Agent 开发的关键问题全部覆盖了。另一个原因是学习助手的反馈信号非常密集。用户说“没听懂”、答错了一道题、主动要求换个讲法这些都是天然的标注数据。没有反馈Agent 就谈不上“自我进化”有了反馈而不知道怎么利用Agent 就只是披着进化外衣的静态系统。学习助手是把反馈闭环做得最自然的领域之一很适合作为理解“自我进化 Agent”的入门项目。从工程可行性的角度看学习助手的需求边界也足够清晰。它不需要调用真实世界的物理接口不需要处理高风险支付操作所有功能都可以在“文本输入输出 检索 存储”范围内实现。这意味着我们可以把注意力集中在 Harness 和上下文设计本身而不是被外部系统对接拖住。所以本文的案例边界是这样定义的一个面向零基础编程学习者的一对一教学 Agent。它能讲解概念、出题测试、分析答错原因并在一段时间的使用后根据学习数据调整讲解风格和教学顺序。它解决的核心问题是如何让同一个大模型对不同的人展现出不同的教学策略并长期维持这种一致性。2. 三个关键概念Harness、上下文工程、自我进化 Agent2.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_k3) 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 驾驭大模型：用Harness构建自我进化的AI学习助手
很多人在 2026 年还会把“AI 学习助手”理解成一个聊天机器人——用户提问模型回答最多套一层提示词。如果只是这样模型的能力上限基本已经到头了。我们真正需要的学习助手不是一个“会说话的百科全书”而是一个能记住你学过的知识、发现你重复犯错、并且能用不同方式重新教你一遍的个性化 Agent。但要做到这一步光靠“换更好的 Prompt”“换更大的模型”是远远不够的。真正决定一个 Agent 是“可控的生产工具”还是“随时跑偏的玩具”的是它外面那层引擎——也就是 Harness中文社区通常翻译成“驾驭工程”或“闸道工程”。它管住了模型能看什么、能做什么、不能做什么同时承接上下文工程和反馈闭环。这篇文章会用一个“编程学习助手”的开发案例把 Harness、上下文工程、自我进化 Agent 这三件事串起来讲清楚。先把一个核心判断放在前面2026 年的 AI 应用开发竞争焦点已经从“选哪个模型”迁移到“怎么驾驭模型”。模型能力差距在缩小工程层的差距在拉大。对一个学习助手来说尤其如此——同样的模型有人能让它因材施教有人只能让它输出干巴巴的百科文本差别几乎全在 Harness 和上下文设计上。读完全文你会知道如何设计一个带约束、带记忆、能调整策略的 Agent也能把它套用到问答助手、编程陪练、知识库搜索等其他场景。1. 为什么要做“学习助手开发”这个案例先说为什么选学习助手。它看起来简单实际是整个 AI Agent 工程能力的一个“微缩战场”。普通聊天机器人只需要“用户问 - 模型答”一个回合这几乎不需要状态管理。学习助手不一样用户今天学 Python 基础明天学异常处理后天可能又把基础忘了。你要让模型知道昨天发生了什么还要让它根据用户的答题表现决定今天先讲哪个概念。这背后涉及状态管理、记忆存储、策略调整、内容检索几乎把 Agent 开发的关键问题全部覆盖了。另一个原因是学习助手的反馈信号非常密集。用户说“没听懂”、答错了一道题、主动要求换个讲法这些都是天然的标注数据。没有反馈Agent 就谈不上“自我进化”有了反馈而不知道怎么利用Agent 就只是披着进化外衣的静态系统。学习助手是把反馈闭环做得最自然的领域之一很适合作为理解“自我进化 Agent”的入门项目。从工程可行性的角度看学习助手的需求边界也足够清晰。它不需要调用真实世界的物理接口不需要处理高风险支付操作所有功能都可以在“文本输入输出 检索 存储”范围内实现。这意味着我们可以把注意力集中在 Harness 和上下文设计本身而不是被外部系统对接拖住。所以本文的案例边界是这样定义的一个面向零基础编程学习者的一对一教学 Agent。它能讲解概念、出题测试、分析答错原因并在一段时间的使用后根据学习数据调整讲解风格和教学顺序。它解决的核心问题是如何让同一个大模型对不同的人展现出不同的教学策略并长期维持这种一致性。2. 三个关键概念Harness、上下文工程、自我进化 Agent2.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_k3) 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