在 AI 编程工具快速迭代的这两年大家应该都有一个很直观的感受模型能力越来越强但真正把模型接到项目里做“可控代码生成”远比想象中麻烦。直接给模型一个任务描述得到的代码要么能跑但不符合项目规范要么改一版崩一版要么上下文一长就越来越飘。我在多个业务项目里尝试用 LLM 生成代码最终发现问题的关键不在模型本身而在于缺少一层“约束和驱动”的外部工程结构。这层结构在业界通常被称为 Harness。本文不聊概念名词本身而是围绕“有哪些 Harness 实践能生成可控代码”这个主题从原理到实战从工具链到避坑经验做一次完整梳理。文章适合三类读者一是想用大模型辅助开发但总被“不可控”困扰的工程师二是准备在团队内落地 AI 编码工具的技术负责人三是想深入理解 Agent 工程实践的进阶开发者。读完你会掌握 Harness 的核心组成、常见实践类型以及一套可以复制到项目里的最小实现方案。1. 什么是 Harness为什么它能提高代码可控性1.1 Harness 的通俗解释Harness 这个词直译过来是“挽具、控制装置”在 AI Agent 工程里它指的是围绕大模型建立的整套外部逻辑框架包含提示词组织、工具调用、上下文管理、执行环境和结果校验规则。举一个容易理解的例子模型像一位能力很强但性格跳脱的工程师你直接把需求告诉他他会自由发挥而 Harness 像是给他配的一张任务卡、一份项目代码规范、一个只能访问特定目录的沙箱再加一个必须跑通单元测试才能提交的验收流程。工程师还是那个工程师但工作方式和产出质量完全不一样。换句话说Harness 不是模型的一部分而是模型之外、由开发者编写和维护的一套工程代码。1.2 为什么直接调模型生成代码不够可控只靠一个带有代码生成功能的模型配合自然语言对话通常会出现下面几类问题生成代码不符合项目现有风格和目录结构比如项目里统一用 TypeScript 严格模式模型却生成 JavaScript 宽松代码。模型会“脑补”不存在的依赖、函数或 API导致生成的代码根本无法通过编译。无法自动验证生成结果代码能写出来但没人知道它能不能跑、对不对。上下文一长模型会遗忘早期约束输出逐渐偏离初始需求。缺少工具能力模型只能“写代码”没法自己读文件、跑测试、看报错并迭代修复。Harness 的核心价值就是通过工程手段解决这些问题。它让模型的行为从“自由生成”变成“在约束框架内生成、执行、反馈、再生成”的闭环。1.3 Harness 与 Agent 的区别热词里有不少人在搜“Harness 和 Agent 区别”这里有必要做个区分。Agent 通常指具备自主决策和行动能力的系统它内部可能包含模型、工具、规划器、记忆等模块。而 Harness 更多强调外部约束和运行框架它不决定模型“想做什么”而是决定模型“能做什么、怎么做、做到什么程度才算完成”。可以理解为Harness 是 Agent 的骨架和缰绳。一个完整的编码 Agent 系统内部一定包含 Harness 设计但 Harness 不一定等于完整的 Agent。实际工程中我们往往先设计好 Harness再在它上面叠加规划、多轮对话、多智能体协作等能力。2. Harness 实践的整体架构与分类2.1 一个典型的代码生成 Harness 包括哪些模块我在项目里落地时通常把 Harness 拆成下面五个模块模块职责常见实现上下文管理收集项目结构、文件内容、需求、约束仓库索引、文件读取器、令牌预算工具定义让模型可以调用外部能力read_file、write_file、run_tests、execute_command输出约束限制模型输出的格式和内容JSON Schema、Pydantic、结构化提示执行沙箱在隔离环境中运行生成代码Docker、本地容器、受限子进程反馈闭环根据执行结果驱动下一轮生成编译错误反馈、测试失败反馈、人工评审这五个模块不是必须全部实现根据项目场景可以裁剪。但如果你追求的是“可控”反馈闭环和输出约束是优先级最高的两块。2.2 常见的 Harness 实践类型综合我在项目里的应用以及近期行业内的讨论下面几种实践对“生成可控代码”的贡献最明显。第一种是评审-修改循环实践。模型先生成一段代码然后由一个评审环节检查这段代码是否符合规范评审可以由规则、静态检查工具或者另一个模型完成不符合就带着问题描述回到生成环节。第二种是测试驱动生成实践。先让模型阅读测试用例再生成能让测试通过的实现代码。这种方式不是让模型自由发挥而是让测试成为最硬性的约束。实测中这种方式生成的代码通常比自然语言需求生成的代码准确率高很多。第三种是仓库级上下文实践。单纯的对话式代码生成只能看到用户粘贴进来的少量代码效果有限。仓库级 Harness 会把项目的目录树、关键文件内容、依赖清单、代码风格配置都注入上下文让模型在充分了解项目的前提下生成代码。第四种是结构化输出约束实践。强制模型输出带格式的代码块、JSON 结构或调用计划而不是一段自由文本。这样后续程序可以准确解析模型输出并执行后续动作。第五种是工具白名单与权限控制实践。模型只能调用 Harness 预先定义好的工具这些工具被限定在项目目录内禁止访问系统敏感路径或执行高危操作。这样就算模型生成错误代码或恶意代码也不会造成大的破坏。这些实践经常组合使用不是在同一个项目里单独存在。下面我会先讲环境准备然后从零实现一个最简 Harness最后再把各类实践融入到这个工程里面。3. 环境准备与版本说明3.1 运行环境与依赖本文示例在 Ubuntu 22.04 系统上验证macOS 也兼容。核心运行环境如下Python 3.10 或更高版本。OpenAI Python SDK用于调用兼容 OpenAI 接口的大模型服务。Pydantic v2用于定义结构化输出格式。Typer用于编写命令行入口也可以用 argparse 代替。本地代码目录示例采用 Python 项目方便验证。版本信息按我实际验证的配置写具体版本可以这样安装pip install openai pydantic typer如果你使用的是 DeepSeek、通义千问或其他兼容 OpenAI 协议的服务只需要调整 base_url 和 model 名称即可。本文示例以 DeepSeek 兼容接口为演示对象base_url 配置为https://api.deepseek.com模型名按官方实际提供的为准。如果本地网络无法访问外部模型服务也可以使用 Ollama 拉起本地模型接口兼容性需要做小量适配。3.2 示例项目结构为了方便演示我设计了这样一个项目结构code-harness-demo/ ├── harness/ │ ├── __init__.py │ ├── core.py # Harness 核心控制循环 │ ├── tools.py # 工具定义 │ ├── schema.py # 输出格式定义 │ └── prompts.py # 提示词组装 ├── workspace/ # 模型可以读写的沙箱目录 │ └── task.md ├── example.py # 命令行入口 └── requirements.txt后续所有代码都放在这个结构里。workspace目录模拟模型的“工作区”模型只能在这个目录里创建和修改文件这样即使模型生成异常代码也不会影响系统其他部分。4. 核心原理拆解Harness 如何约束模型行为4.1 上下文装配让模型真正“看懂”项目直接调用大模型生成代码最常见的错误就是模型完全不了解项目的目录结构。解决办法是在每次请求前Harness 自动扫描工作目录把目录树和关键文件内容注入系统提示词。一个简单的目录树生成函数如下# harness/tools.py import os from pathlib import Path def get_directory_tree(root: Path, max_depth: int 3) - str: 生成工作目录的树状结构文本限制深度避免上下文膨胀。 lines [] root root.resolve() def walk(current: Path, depth: int): if depth max_depth: return indent * depth if current.is_dir(): lines.append(f{indent}{current.name}/) for child in sorted(current.iterdir()): if child.name.startswith(.git): continue walk(child, depth 1) else: lines.append(f{indent}{current.name}) walk(root, 0) return \n.join(lines)注意这里的令牌预算问题。大模型有上下文长度限制目录树和文件内容不能无限塞进去。实际项目中建议只注入用户指定文件、最近修改文件、项目入口文件而不是所有文件。一个常见的做法是设置单文件最大字符数超过部分截断并提示“文件过长请使用工具按需读取”。4.2 输出约束用结构化格式锁住模型输出让模型输出纯自然语言文本后续程序很难解析。Harness 的常见做法是要求模型输出 JSON并定义 JSON 字段。比如定义一个调用计划结构{ thought: 分析任务并决定下一步动作, action: read_file, action_input: {path: workspace/task.md}, completed: false }在 Python 侧使用 Pydantic 做结构化校验模型输出一旦不符合 schema就重新请求或抛出错误。# harness/schema.py from pydantic import BaseModel, Field class AgentAction(BaseModel): thought: str Field(description思考过程) action: str Field(description工具名称) action_input: dict Field(description工具参数) completed: bool Field(description是否已完成任务)把这段 JSON 结构放进提示词明确告诉模型每一步必须输出 JSON并且只能调用系统列出的工具。这样模型的行为就从“自由对话”变成了“带格式的动作序列”。4.3 工具调用控制限制模型的行动边界工具调用是 Harness 最具价值的部分。模型生成的动作只有经过 Harness 白名单校验才会被执行。比如模型想调用一个叫delete_system的工具但 Harness 里根本没有这个工具请求会直接失败。下面是一个简化版的工具执行器# harness/tools.py import subprocess from pathlib import Path class ToolRegistry: def __init__(self, workspace: Path): self.workspace workspace self.tools { read_file: self.read_file, write_file: self.write_file, run_tests: self.run_tests, } def read_file(self, path: str) - str: full_path (self.workspace / path).resolve() # 关键点必须校验路径是否在 workspace 内防止目录穿越 if not str(full_path).startswith(str(self.workspace.resolve())): return Error: path is outside workspace if not full_path.exists(): return Error: file not found return full_path.read_text(encodingutf-8) def write_file(self, path: str, content: str) - str: full_path (self.workspace / path).resolve() if not str(full_path).startswith(str(self.workspace.resolve())): return Error: path is outside workspace full_path.parent.mkdir(parentsTrue, exist_okTrue) full_path.write_text(content, encodingutf-8) return fFile written: {path} def run_tests(self) - str: result subprocess.run( [python, -m, pytest, str(self.workspace)], capture_outputTrue, textTrue, timeout30, ) return result.stdout result.stderr这里有个很关键的安全点工具函数内部必须做路径规范化校验。模型生成的路径如果包含../直接拼接会导致目录穿越。先用resolve()转成绝对路径再判断是否以工作区路径开头这个检查能拦截绝大多数越界访问。4.4 反馈闭环让模型自己看报错和修代码可控代码生成的核心并不在第一次生成而在后续迭代。第一次生成往往有各种问题重要的是让模型拿到编译器输出、测试结果后自行修改。这个闭环流程可以用一个循环来描述初始化系统提示词包含工具列表和任务说明。模型输出一条 AgentAction。如果 completed 为 true结束循环。否则执行 action 对应的工具。把工具执行结果作为新的消息追加给模型。回到第 2 步。这样模型遇到测试失败时会主动读取报错文件、修改代码、重新跑测试直到测试通过或达到最大迭代轮数。5. 完整实战从零实现一个最小可控代码 Harness5.1 创建项目结构先创建工程目录mkdir -p code-harness-demo/harness mkdir -p code-harness-demo/workspace cd code-harness-demo touch harness/__init__.py5.2 编写提示词组装模块提示词是 Harness 中最“软”但最影响效果的部分。它需要把工具列表、工作目录结构、任务描述、输出格式要求全部组织在一起。# harness/prompts.py from .tools import get_directory_tree from pathlib import Path SYSTEM_PROMPT_TEMPLATE 你是一个运行在自动化工程环境中的代码生成助手。 工作目录结构如下 {tree} 你可以使用以下工具 {tool_descriptions} 所有路径必须基于工作目录。禁止访问工作目录之外的任何文件。 你必须严格输出 JSON 格式格式如下 {{ thought: 你的思考, action: 工具名, action_input: {{参数名: 参数值}}, completed: false }} 如果任务完成请将 completed 设为 true并生成最终代码说明。 def build_system_prompt(workspace: Path, tool_descriptions: str) - str: tree get_directory_tree(workspace) return SYSTEM_PROMPT_TEMPLATE.format( treetree, tool_descriptionstool_descriptions, )需要特别注意的是 JSON 示例里的花括号。在 Python 字符串格式化时JSON 示例里的花括号需要用双花括号转义否则会被当成占位符。上面代码中已经做了处理实际写的时候很容易漏掉这一点。5.3 编写核心循环核心循环负责调用模型、解析输出、执行工具、追加反馈。# harness/core.py import json from openai import OpenAI from typing import List, Dict from .schema import AgentAction from .prompts import build_system_prompt from .tools import ToolRegistry class CodeHarness: def __init__( self, workspace: str, model: str deepseek-chat, base_url: str https://api.deepseek.com, max_steps: int 10, ): self.workspace Path(workspace) self.client OpenAI(base_urlbase_url) self.model model self.max_steps max_steps self.tools ToolRegistry(self.workspace) self.messages: List[Dict[str, str]] [] def run(self, task: str) - str: system_prompt build_system_prompt( self.workspace, tool_descriptions, .join(self.tools.tools.keys()), ) self.messages [ {role: system, content: system_prompt}, {role: user, content: task}, ] for step in range(self.max_steps): print(f\n Step {step 1} ) response self.client.chat.completions.create( modelself.model, messagesself.messages, temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content print(模型输出:, content) try: parsed json.loads(content) action AgentAction(**parsed) except Exception as e: error_msg f输出解析失败: {e}请严格按照要求输出 JSON。 self.messages.append({role: user, content: error_msg}) continue if action.completed: return action.thought tool_func self.tools.tools.get(action.action) if tool_func is None: feedback f工具 {action.action} 不存在可用工具: {list(self.tools.tools.keys())} else: feedback tool_func(**action.action_input) self.messages.append({role: assistant, content: content}) self.messages.append({role: user, content: f工具执行结果{feedback}}) return 达到最大执行步数任务未完成这个循环的好处是简单、直观适合理解 Harness 的核心机制。实际生产系统中还要加入 token 计数、错误重试、并发控制等增强逻辑但基本骨架就是这样。5.4 编写命令行入口为了方便验证写一个简单的命令行入口# example.py from pathlib import Path from harness.core import CodeHarness def main(): workspace Path(workspace) task 读取 workspace/task.md 中描述的需求在 workspace 下创建一个 Python 文件实现需求并编写 pytest 测试最后运行测试确保通过。 harness CodeHarness(workspaceworkspace) result harness.run(task) print(\n最终结果:, result) if __name__ __main__: main()5.5 创建演示任务在 workspace 目录下创建一个任务描述文件# workspace/task.md 实现一个函数 is_palindrome(s: str) - bool判断字符串是否为回文。忽略大小写和非字母数字字符。 要求在 workspace 下创建 palindrome.py 和 test_palindrome.py使用 pytest 编写测试用例并确保测试通过。5.6 运行与验证执行命令python example.py预期运行过程会看到多个步骤模型读取任务文件创建代码文件创建测试文件运行测试如果有失败则继续修改最终 completed 为 true。由于不同模型输出会有差异这里不给出固定输出文本但整体流程一定是“生成-执行-反馈-再生成”的循环。5.7 结果说明通过这个例子可以很直观地看到 Harness 的约束价值。模型永远无法“直接交付答案”它必须调用工具创建真实文件必须通过 pytest 验证才能宣布任务完成。这比普通对话式生成多了一层硬性保障代码质量自然更可控。6. 从最小实现到生产级更丰富的 Harness 实践6.1 评审-修改循环实践最小实现里已经包含“测试反馈”这一层约束但测试只能验证行为验证不了代码风格。生产环境可以在 Harness 中加入一个评审步骤让另一个模型扮演资深工程师从代码规范、可读性、安全隐患角度提出意见。实现思路如下模型生成代码并让测试通过。调用评审模型的接口输入代码和评审标准。评审模型输出问题清单。把问题清单返回给第一模型要求修改。循环若干轮直到评审通过或达到最大轮数。这样等于在生成 Harness 外面又套了一层校验 Harness。代价是多消耗模型调用次数和延迟但换来的可控性提升非常明显。6.2 仓库级上下文增强最简实现里只有目录树没有文件内容。真实项目里模型需要了解现有代码才能生成风格一致的代码。仓库级上下文增强通常包括读取项目的pyproject.toml、package.json等依赖清单让模型知道可用依赖版本。读取项目入口文件、配置文件、README让模型了解项目目标。建立代码索引让模型可以先搜索再读取而不是一次性塞入所有文件。读取.editorconfig、.eslintrc等风格配置作为生成代码的风格约束。在实现上我建议在工具列表里增加一个search_files工具模型可以通过关键词搜索文件或代码片段再决定读取哪些文件。这样能大幅降低上下文占用同时让模型获取到更有针对性的信息。6.3 多智能体协作实践在复杂任务下让一个模型从头到尾完成所有工作很容易出现上下文膨胀、任务漂移。更稳妥的思路是拆分角色规划者把大任务拆成子任务每个子任务确定输入输出。程序员负责实现某个子任务的代码。测试员负责编写并运行测试。评审员负责检查风格和安全问题。每个角色使用独立的会话之间通过文件或消息队列传递产物。这种多智能体模式的核心优势是每个模型上下文更短、职责更明确单个角色的“失控”很难影响全局。缺点是实现复杂度高DevOps 成本和 token 成本都明显上升。我自己实践下来的感受是先别急着上多智能体单智能体加测试闭环已经能解决 80% 的代码生成可控性问题。多智能体适合任务边界清晰、需要并行开发的场景否则反而更容易互相干扰。6.4 结构化输出约束的进阶用法最简实现中使用 JSON 作为模型输出格式。生产级系统可以考虑使用更严格的 JSON Schema并且在每次模型输出后做 schema 校验校验失败就带着错误信息重新请求。另一个进阶用法是让模型先输出“计划”再输出“动作”。比如要求模型每一轮先输出{ plan: [读取需求文件, 创建实现代码, 运行测试], current_step: 1 }这样做的好处是让模型在每一步都保留全局计划减少中途偏离需求的风险。代价是上下文更长、请求更慢。在任务步骤不多时这种冗余设计收益有限。6.5 沙箱执行实践最简实现里run_tests是直接在本机执行的这在真实环境里有风险。模型有可能生成恶意代码或者代码本身包含rm -rf之类的危险操作。生产环境推荐使用 Docker 作为沙箱。基本思路是每次运行前构建一个只包含必要依赖的 Docker 镜像把 workspace 挂载到容器内在容器内执行测试命令只返回标准输出和错误信息。容器可以设置内存限制、CPU 限制和网络禁止访问。Docker 运行命令示例docker run --rm \ -v $(pwd)/workspace:/workspace \ -w /workspace \ --memory512m \ --cpus1 \ --networknone \ python:3.11-slim \ sh -c pip install pytest -q python -m pytest如果团队没有 Docker 环境也可以用 Python 的subprocess配合资源限制实现轻量沙箱但隔离强度弱很多。我这里强调一点即使使用沙箱也要守好路径白名单不要因为有了 Docker 就放松对工具调用边界的校验。7. 常见问题与排查思路7.1 模型输出 JSON 解析失败问题现象常见原因解决思路json.loads 抛异常模型输出了多余文本或格式错误在提示词中强调仅输出 JSON增加重试逻辑模型输出 Markdown 代码块提示词未约束格式在解析前先剥离 json 标记同时优化提示词字段缺少response_format 未开启或模型不支持确认接口支持 json_object 模式低版本模型可改用正则抽取有些模型服务不支持response_format参数或者对json_object支持不稳定。遇到这种情况可以在解析时做容错处理先尝试json.loads失败后去掉首尾的 Markdown 代码块标记再试一次如果还失败就返回错误提示让模型重新输出。建议在请求参数里加一个开关由配置决定是否传入response_format。7.2 模型长时间不调工具一直输出 completed这种情况通常意味着模型在“偷懒”没有真正完成任务就宣布结束。原因可能是任务描述不明确或者系统提示词中的验收标准不严格。解决方案是在提示词中把验收标准写死“你没有运行过 pytest 之前禁止设置 completed 为 true。”“如果工作目录中没有生成对应的.py文件禁止设置 completed 为 true。”同时在代码层面校验可以在 completed 为 true 时额外检查工作目录中是否存在预期产物如果没有则忽略完成信号并强制模型继续。7.3 上下文长度超限项目文件多、上下文装配太激进是最常见原因。排查思路是看报错是 prompt 超限还是 history 超限。如果 prompt 超限缩短目录树深度、减少自动注入文件数量、增加单文件截断策略。如果 history 超限压缩历史消息比如只保留最近三轮对话加工具结果。引入摘要机制在对话轮数增加时把早期讨论摘要成一段简短的“已完成事项”注入到系统提示词。在模型 api 的入参里还可以开启自动截断但我不建议完全依赖它因为可能会把关键约束截掉。7.4 生成代码能跑但不符合项目规范这是“测试通过但质量差”的典型场景。测试只验证正确性验证不了风格。解决思路在提示词中注入项目的.editorconfig、flake8、mypy配置。在工具列表里增加run_lint工具用静态检查工具的结果作为反馈。引入评审模型弥补单一模型的视角盲区。7.5 Harness 循环陷入死循环模型来回修改代码但测试一直不通过直到达到 max_steps。应对措施设置最大迭代轮数避免无限消耗 token。每轮反馈中附带上一次错误信息避免模型重复犯同样的错。如果连续三轮输出相同的修改意图直接中断并生成失败报告。人工介入机制某个子任务失败次数过多时通知开发者手动处理。8. 最佳实践与工程建议8.1 从最小闭环开始不要一步到位很多团队设计 AI 编码 Harness 时容易过度设计一开始就上多智能体、向量数据库、复杂记忆系统。我的建议是先把“任务-生成-测试-反馈”这个最小闭环跑通然后把项目日常需求丢进去验证效果再逐步加能力。这样定位问题会容易很多。8.2 路径安全是不可妥协的底线无论模型多强工具调用边界必须由 Harness 强制约束。所有文件操作都要做路径规范化校验禁止访问工作区之外所有命令执行都要限制超时时间生产环境一定要使用容器或虚拟机隔离。安全不是可选项是使用 AI 生成代码的前提。8.3 提示词中的约束要“重复但不冗余”系统提示词里工具列表要说一次工具描述里要再说一次用户任务里可以再强调一次。模型对长上下文中的信息存在注意力衰减关键约束的适度重复能有效提升遵循率。但不要每轮都重复全部约束否则会占用上下文空间影响模型对任务信息的关注度。8.4 为模型提供可验证的验收标准可控性的核心来自可验证的验收标准。如果任务目标是“优化代码”模型永远不知道什么时候算完成如果目标是“修复 test_xxx.py 中的 3 个失败用例”模型就有了清晰终点。在实际业务中尽量把需求描述转换成可以自动验证的测试用例或检查规则。8.5 日志与审计Harness 运行过程往往不可完全预测必须记录完整的运行日志。建议至少记录以下信息模型输入输出的完整消息。每一步执行的工具和参数。工具返回结果。每次完成的耗时和 token 消耗。最终生成的代码产物。这样无论是排查模型行为异常还是统计成本都有据可依。同时建议对 Harness 的配置变更也做版本管理避免调参后无法回滚。8.6 权限与最小化原则生产系统里Harness 使用的 API Key 要独立于业务系统权限最小化只能访问模型服务不能访问数据库和其他内部系统。工作目录和 Git 仓库分离模型生成的内容先经过人工或 CI 检查再决定是否合并到主分支。涉及生产环境变更时必须先经过完整测试环境验证不允许 Harness 直接操作生产资源。9. 总结与下一步学习方向我在多个场景中反复验证单纯靠换更大参数的模型并不能让代码生成变得可控。真正起作用的是 Harness 工程把模型从“自由生成器”变成“受约束的任务求解器”并通过工具调用、测试反馈、结构化输出、沙箱执行这些外部机制将模型能力锁在可控范围内。本文从最基础的最小闭环出发给出了一套可以完整运行的 Python Harness 实现在此基础上又展开了评审-修改循环、仓库级上下文、多智能体协作、沙箱执行等生产级实践。你可以把这套代码拿回去改造先替换成团队自己的模型服务地址和工具列表再用真实需求压测逐步形成适合自己项目的 Harness 方案。下一步建议从这几个方向深入第一研究 Codex、DeepSeek Harness 等开源项目的代码实现参考它们在 Agent 循环、上下文压缩和工具设计上的细节第二学习 Prompt 工程中的高级方法比如示例选择、思维链、few-shot 设计这些能显著提升 Harness 内模型输出的稳定性第三关注测试生成和代码评审这两个方向这是让 Harness 具备“自校验能力”的关键闭环。代码生成的可控性没有终点模型能力会继续增强但 Harness 工程的价值不会减弱。因为越是强大的模型越需要清晰的边界和可靠的验收机制而这个边界恰恰是我们这些做工程的人最擅长的事。 Harness 实践指南：如何用外部约束让大模型生成可控代码
在 AI 编程工具快速迭代的这两年大家应该都有一个很直观的感受模型能力越来越强但真正把模型接到项目里做“可控代码生成”远比想象中麻烦。直接给模型一个任务描述得到的代码要么能跑但不符合项目规范要么改一版崩一版要么上下文一长就越来越飘。我在多个业务项目里尝试用 LLM 生成代码最终发现问题的关键不在模型本身而在于缺少一层“约束和驱动”的外部工程结构。这层结构在业界通常被称为 Harness。本文不聊概念名词本身而是围绕“有哪些 Harness 实践能生成可控代码”这个主题从原理到实战从工具链到避坑经验做一次完整梳理。文章适合三类读者一是想用大模型辅助开发但总被“不可控”困扰的工程师二是准备在团队内落地 AI 编码工具的技术负责人三是想深入理解 Agent 工程实践的进阶开发者。读完你会掌握 Harness 的核心组成、常见实践类型以及一套可以复制到项目里的最小实现方案。1. 什么是 Harness为什么它能提高代码可控性1.1 Harness 的通俗解释Harness 这个词直译过来是“挽具、控制装置”在 AI Agent 工程里它指的是围绕大模型建立的整套外部逻辑框架包含提示词组织、工具调用、上下文管理、执行环境和结果校验规则。举一个容易理解的例子模型像一位能力很强但性格跳脱的工程师你直接把需求告诉他他会自由发挥而 Harness 像是给他配的一张任务卡、一份项目代码规范、一个只能访问特定目录的沙箱再加一个必须跑通单元测试才能提交的验收流程。工程师还是那个工程师但工作方式和产出质量完全不一样。换句话说Harness 不是模型的一部分而是模型之外、由开发者编写和维护的一套工程代码。1.2 为什么直接调模型生成代码不够可控只靠一个带有代码生成功能的模型配合自然语言对话通常会出现下面几类问题生成代码不符合项目现有风格和目录结构比如项目里统一用 TypeScript 严格模式模型却生成 JavaScript 宽松代码。模型会“脑补”不存在的依赖、函数或 API导致生成的代码根本无法通过编译。无法自动验证生成结果代码能写出来但没人知道它能不能跑、对不对。上下文一长模型会遗忘早期约束输出逐渐偏离初始需求。缺少工具能力模型只能“写代码”没法自己读文件、跑测试、看报错并迭代修复。Harness 的核心价值就是通过工程手段解决这些问题。它让模型的行为从“自由生成”变成“在约束框架内生成、执行、反馈、再生成”的闭环。1.3 Harness 与 Agent 的区别热词里有不少人在搜“Harness 和 Agent 区别”这里有必要做个区分。Agent 通常指具备自主决策和行动能力的系统它内部可能包含模型、工具、规划器、记忆等模块。而 Harness 更多强调外部约束和运行框架它不决定模型“想做什么”而是决定模型“能做什么、怎么做、做到什么程度才算完成”。可以理解为Harness 是 Agent 的骨架和缰绳。一个完整的编码 Agent 系统内部一定包含 Harness 设计但 Harness 不一定等于完整的 Agent。实际工程中我们往往先设计好 Harness再在它上面叠加规划、多轮对话、多智能体协作等能力。2. Harness 实践的整体架构与分类2.1 一个典型的代码生成 Harness 包括哪些模块我在项目里落地时通常把 Harness 拆成下面五个模块模块职责常见实现上下文管理收集项目结构、文件内容、需求、约束仓库索引、文件读取器、令牌预算工具定义让模型可以调用外部能力read_file、write_file、run_tests、execute_command输出约束限制模型输出的格式和内容JSON Schema、Pydantic、结构化提示执行沙箱在隔离环境中运行生成代码Docker、本地容器、受限子进程反馈闭环根据执行结果驱动下一轮生成编译错误反馈、测试失败反馈、人工评审这五个模块不是必须全部实现根据项目场景可以裁剪。但如果你追求的是“可控”反馈闭环和输出约束是优先级最高的两块。2.2 常见的 Harness 实践类型综合我在项目里的应用以及近期行业内的讨论下面几种实践对“生成可控代码”的贡献最明显。第一种是评审-修改循环实践。模型先生成一段代码然后由一个评审环节检查这段代码是否符合规范评审可以由规则、静态检查工具或者另一个模型完成不符合就带着问题描述回到生成环节。第二种是测试驱动生成实践。先让模型阅读测试用例再生成能让测试通过的实现代码。这种方式不是让模型自由发挥而是让测试成为最硬性的约束。实测中这种方式生成的代码通常比自然语言需求生成的代码准确率高很多。第三种是仓库级上下文实践。单纯的对话式代码生成只能看到用户粘贴进来的少量代码效果有限。仓库级 Harness 会把项目的目录树、关键文件内容、依赖清单、代码风格配置都注入上下文让模型在充分了解项目的前提下生成代码。第四种是结构化输出约束实践。强制模型输出带格式的代码块、JSON 结构或调用计划而不是一段自由文本。这样后续程序可以准确解析模型输出并执行后续动作。第五种是工具白名单与权限控制实践。模型只能调用 Harness 预先定义好的工具这些工具被限定在项目目录内禁止访问系统敏感路径或执行高危操作。这样就算模型生成错误代码或恶意代码也不会造成大的破坏。这些实践经常组合使用不是在同一个项目里单独存在。下面我会先讲环境准备然后从零实现一个最简 Harness最后再把各类实践融入到这个工程里面。3. 环境准备与版本说明3.1 运行环境与依赖本文示例在 Ubuntu 22.04 系统上验证macOS 也兼容。核心运行环境如下Python 3.10 或更高版本。OpenAI Python SDK用于调用兼容 OpenAI 接口的大模型服务。Pydantic v2用于定义结构化输出格式。Typer用于编写命令行入口也可以用 argparse 代替。本地代码目录示例采用 Python 项目方便验证。版本信息按我实际验证的配置写具体版本可以这样安装pip install openai pydantic typer如果你使用的是 DeepSeek、通义千问或其他兼容 OpenAI 协议的服务只需要调整 base_url 和 model 名称即可。本文示例以 DeepSeek 兼容接口为演示对象base_url 配置为https://api.deepseek.com模型名按官方实际提供的为准。如果本地网络无法访问外部模型服务也可以使用 Ollama 拉起本地模型接口兼容性需要做小量适配。3.2 示例项目结构为了方便演示我设计了这样一个项目结构code-harness-demo/ ├── harness/ │ ├── __init__.py │ ├── core.py # Harness 核心控制循环 │ ├── tools.py # 工具定义 │ ├── schema.py # 输出格式定义 │ └── prompts.py # 提示词组装 ├── workspace/ # 模型可以读写的沙箱目录 │ └── task.md ├── example.py # 命令行入口 └── requirements.txt后续所有代码都放在这个结构里。workspace目录模拟模型的“工作区”模型只能在这个目录里创建和修改文件这样即使模型生成异常代码也不会影响系统其他部分。4. 核心原理拆解Harness 如何约束模型行为4.1 上下文装配让模型真正“看懂”项目直接调用大模型生成代码最常见的错误就是模型完全不了解项目的目录结构。解决办法是在每次请求前Harness 自动扫描工作目录把目录树和关键文件内容注入系统提示词。一个简单的目录树生成函数如下# harness/tools.py import os from pathlib import Path def get_directory_tree(root: Path, max_depth: int 3) - str: 生成工作目录的树状结构文本限制深度避免上下文膨胀。 lines [] root root.resolve() def walk(current: Path, depth: int): if depth max_depth: return indent * depth if current.is_dir(): lines.append(f{indent}{current.name}/) for child in sorted(current.iterdir()): if child.name.startswith(.git): continue walk(child, depth 1) else: lines.append(f{indent}{current.name}) walk(root, 0) return \n.join(lines)注意这里的令牌预算问题。大模型有上下文长度限制目录树和文件内容不能无限塞进去。实际项目中建议只注入用户指定文件、最近修改文件、项目入口文件而不是所有文件。一个常见的做法是设置单文件最大字符数超过部分截断并提示“文件过长请使用工具按需读取”。4.2 输出约束用结构化格式锁住模型输出让模型输出纯自然语言文本后续程序很难解析。Harness 的常见做法是要求模型输出 JSON并定义 JSON 字段。比如定义一个调用计划结构{ thought: 分析任务并决定下一步动作, action: read_file, action_input: {path: workspace/task.md}, completed: false }在 Python 侧使用 Pydantic 做结构化校验模型输出一旦不符合 schema就重新请求或抛出错误。# harness/schema.py from pydantic import BaseModel, Field class AgentAction(BaseModel): thought: str Field(description思考过程) action: str Field(description工具名称) action_input: dict Field(description工具参数) completed: bool Field(description是否已完成任务)把这段 JSON 结构放进提示词明确告诉模型每一步必须输出 JSON并且只能调用系统列出的工具。这样模型的行为就从“自由对话”变成了“带格式的动作序列”。4.3 工具调用控制限制模型的行动边界工具调用是 Harness 最具价值的部分。模型生成的动作只有经过 Harness 白名单校验才会被执行。比如模型想调用一个叫delete_system的工具但 Harness 里根本没有这个工具请求会直接失败。下面是一个简化版的工具执行器# harness/tools.py import subprocess from pathlib import Path class ToolRegistry: def __init__(self, workspace: Path): self.workspace workspace self.tools { read_file: self.read_file, write_file: self.write_file, run_tests: self.run_tests, } def read_file(self, path: str) - str: full_path (self.workspace / path).resolve() # 关键点必须校验路径是否在 workspace 内防止目录穿越 if not str(full_path).startswith(str(self.workspace.resolve())): return Error: path is outside workspace if not full_path.exists(): return Error: file not found return full_path.read_text(encodingutf-8) def write_file(self, path: str, content: str) - str: full_path (self.workspace / path).resolve() if not str(full_path).startswith(str(self.workspace.resolve())): return Error: path is outside workspace full_path.parent.mkdir(parentsTrue, exist_okTrue) full_path.write_text(content, encodingutf-8) return fFile written: {path} def run_tests(self) - str: result subprocess.run( [python, -m, pytest, str(self.workspace)], capture_outputTrue, textTrue, timeout30, ) return result.stdout result.stderr这里有个很关键的安全点工具函数内部必须做路径规范化校验。模型生成的路径如果包含../直接拼接会导致目录穿越。先用resolve()转成绝对路径再判断是否以工作区路径开头这个检查能拦截绝大多数越界访问。4.4 反馈闭环让模型自己看报错和修代码可控代码生成的核心并不在第一次生成而在后续迭代。第一次生成往往有各种问题重要的是让模型拿到编译器输出、测试结果后自行修改。这个闭环流程可以用一个循环来描述初始化系统提示词包含工具列表和任务说明。模型输出一条 AgentAction。如果 completed 为 true结束循环。否则执行 action 对应的工具。把工具执行结果作为新的消息追加给模型。回到第 2 步。这样模型遇到测试失败时会主动读取报错文件、修改代码、重新跑测试直到测试通过或达到最大迭代轮数。5. 完整实战从零实现一个最小可控代码 Harness5.1 创建项目结构先创建工程目录mkdir -p code-harness-demo/harness mkdir -p code-harness-demo/workspace cd code-harness-demo touch harness/__init__.py5.2 编写提示词组装模块提示词是 Harness 中最“软”但最影响效果的部分。它需要把工具列表、工作目录结构、任务描述、输出格式要求全部组织在一起。# harness/prompts.py from .tools import get_directory_tree from pathlib import Path SYSTEM_PROMPT_TEMPLATE 你是一个运行在自动化工程环境中的代码生成助手。 工作目录结构如下 {tree} 你可以使用以下工具 {tool_descriptions} 所有路径必须基于工作目录。禁止访问工作目录之外的任何文件。 你必须严格输出 JSON 格式格式如下 {{ thought: 你的思考, action: 工具名, action_input: {{参数名: 参数值}}, completed: false }} 如果任务完成请将 completed 设为 true并生成最终代码说明。 def build_system_prompt(workspace: Path, tool_descriptions: str) - str: tree get_directory_tree(workspace) return SYSTEM_PROMPT_TEMPLATE.format( treetree, tool_descriptionstool_descriptions, )需要特别注意的是 JSON 示例里的花括号。在 Python 字符串格式化时JSON 示例里的花括号需要用双花括号转义否则会被当成占位符。上面代码中已经做了处理实际写的时候很容易漏掉这一点。5.3 编写核心循环核心循环负责调用模型、解析输出、执行工具、追加反馈。# harness/core.py import json from openai import OpenAI from typing import List, Dict from .schema import AgentAction from .prompts import build_system_prompt from .tools import ToolRegistry class CodeHarness: def __init__( self, workspace: str, model: str deepseek-chat, base_url: str https://api.deepseek.com, max_steps: int 10, ): self.workspace Path(workspace) self.client OpenAI(base_urlbase_url) self.model model self.max_steps max_steps self.tools ToolRegistry(self.workspace) self.messages: List[Dict[str, str]] [] def run(self, task: str) - str: system_prompt build_system_prompt( self.workspace, tool_descriptions, .join(self.tools.tools.keys()), ) self.messages [ {role: system, content: system_prompt}, {role: user, content: task}, ] for step in range(self.max_steps): print(f\n Step {step 1} ) response self.client.chat.completions.create( modelself.model, messagesself.messages, temperature0.2, response_format{type: json_object}, ) content response.choices[0].message.content print(模型输出:, content) try: parsed json.loads(content) action AgentAction(**parsed) except Exception as e: error_msg f输出解析失败: {e}请严格按照要求输出 JSON。 self.messages.append({role: user, content: error_msg}) continue if action.completed: return action.thought tool_func self.tools.tools.get(action.action) if tool_func is None: feedback f工具 {action.action} 不存在可用工具: {list(self.tools.tools.keys())} else: feedback tool_func(**action.action_input) self.messages.append({role: assistant, content: content}) self.messages.append({role: user, content: f工具执行结果{feedback}}) return 达到最大执行步数任务未完成这个循环的好处是简单、直观适合理解 Harness 的核心机制。实际生产系统中还要加入 token 计数、错误重试、并发控制等增强逻辑但基本骨架就是这样。5.4 编写命令行入口为了方便验证写一个简单的命令行入口# example.py from pathlib import Path from harness.core import CodeHarness def main(): workspace Path(workspace) task 读取 workspace/task.md 中描述的需求在 workspace 下创建一个 Python 文件实现需求并编写 pytest 测试最后运行测试确保通过。 harness CodeHarness(workspaceworkspace) result harness.run(task) print(\n最终结果:, result) if __name__ __main__: main()5.5 创建演示任务在 workspace 目录下创建一个任务描述文件# workspace/task.md 实现一个函数 is_palindrome(s: str) - bool判断字符串是否为回文。忽略大小写和非字母数字字符。 要求在 workspace 下创建 palindrome.py 和 test_palindrome.py使用 pytest 编写测试用例并确保测试通过。5.6 运行与验证执行命令python example.py预期运行过程会看到多个步骤模型读取任务文件创建代码文件创建测试文件运行测试如果有失败则继续修改最终 completed 为 true。由于不同模型输出会有差异这里不给出固定输出文本但整体流程一定是“生成-执行-反馈-再生成”的循环。5.7 结果说明通过这个例子可以很直观地看到 Harness 的约束价值。模型永远无法“直接交付答案”它必须调用工具创建真实文件必须通过 pytest 验证才能宣布任务完成。这比普通对话式生成多了一层硬性保障代码质量自然更可控。6. 从最小实现到生产级更丰富的 Harness 实践6.1 评审-修改循环实践最小实现里已经包含“测试反馈”这一层约束但测试只能验证行为验证不了代码风格。生产环境可以在 Harness 中加入一个评审步骤让另一个模型扮演资深工程师从代码规范、可读性、安全隐患角度提出意见。实现思路如下模型生成代码并让测试通过。调用评审模型的接口输入代码和评审标准。评审模型输出问题清单。把问题清单返回给第一模型要求修改。循环若干轮直到评审通过或达到最大轮数。这样等于在生成 Harness 外面又套了一层校验 Harness。代价是多消耗模型调用次数和延迟但换来的可控性提升非常明显。6.2 仓库级上下文增强最简实现里只有目录树没有文件内容。真实项目里模型需要了解现有代码才能生成风格一致的代码。仓库级上下文增强通常包括读取项目的pyproject.toml、package.json等依赖清单让模型知道可用依赖版本。读取项目入口文件、配置文件、README让模型了解项目目标。建立代码索引让模型可以先搜索再读取而不是一次性塞入所有文件。读取.editorconfig、.eslintrc等风格配置作为生成代码的风格约束。在实现上我建议在工具列表里增加一个search_files工具模型可以通过关键词搜索文件或代码片段再决定读取哪些文件。这样能大幅降低上下文占用同时让模型获取到更有针对性的信息。6.3 多智能体协作实践在复杂任务下让一个模型从头到尾完成所有工作很容易出现上下文膨胀、任务漂移。更稳妥的思路是拆分角色规划者把大任务拆成子任务每个子任务确定输入输出。程序员负责实现某个子任务的代码。测试员负责编写并运行测试。评审员负责检查风格和安全问题。每个角色使用独立的会话之间通过文件或消息队列传递产物。这种多智能体模式的核心优势是每个模型上下文更短、职责更明确单个角色的“失控”很难影响全局。缺点是实现复杂度高DevOps 成本和 token 成本都明显上升。我自己实践下来的感受是先别急着上多智能体单智能体加测试闭环已经能解决 80% 的代码生成可控性问题。多智能体适合任务边界清晰、需要并行开发的场景否则反而更容易互相干扰。6.4 结构化输出约束的进阶用法最简实现中使用 JSON 作为模型输出格式。生产级系统可以考虑使用更严格的 JSON Schema并且在每次模型输出后做 schema 校验校验失败就带着错误信息重新请求。另一个进阶用法是让模型先输出“计划”再输出“动作”。比如要求模型每一轮先输出{ plan: [读取需求文件, 创建实现代码, 运行测试], current_step: 1 }这样做的好处是让模型在每一步都保留全局计划减少中途偏离需求的风险。代价是上下文更长、请求更慢。在任务步骤不多时这种冗余设计收益有限。6.5 沙箱执行实践最简实现里run_tests是直接在本机执行的这在真实环境里有风险。模型有可能生成恶意代码或者代码本身包含rm -rf之类的危险操作。生产环境推荐使用 Docker 作为沙箱。基本思路是每次运行前构建一个只包含必要依赖的 Docker 镜像把 workspace 挂载到容器内在容器内执行测试命令只返回标准输出和错误信息。容器可以设置内存限制、CPU 限制和网络禁止访问。Docker 运行命令示例docker run --rm \ -v $(pwd)/workspace:/workspace \ -w /workspace \ --memory512m \ --cpus1 \ --networknone \ python:3.11-slim \ sh -c pip install pytest -q python -m pytest如果团队没有 Docker 环境也可以用 Python 的subprocess配合资源限制实现轻量沙箱但隔离强度弱很多。我这里强调一点即使使用沙箱也要守好路径白名单不要因为有了 Docker 就放松对工具调用边界的校验。7. 常见问题与排查思路7.1 模型输出 JSON 解析失败问题现象常见原因解决思路json.loads 抛异常模型输出了多余文本或格式错误在提示词中强调仅输出 JSON增加重试逻辑模型输出 Markdown 代码块提示词未约束格式在解析前先剥离 json 标记同时优化提示词字段缺少response_format 未开启或模型不支持确认接口支持 json_object 模式低版本模型可改用正则抽取有些模型服务不支持response_format参数或者对json_object支持不稳定。遇到这种情况可以在解析时做容错处理先尝试json.loads失败后去掉首尾的 Markdown 代码块标记再试一次如果还失败就返回错误提示让模型重新输出。建议在请求参数里加一个开关由配置决定是否传入response_format。7.2 模型长时间不调工具一直输出 completed这种情况通常意味着模型在“偷懒”没有真正完成任务就宣布结束。原因可能是任务描述不明确或者系统提示词中的验收标准不严格。解决方案是在提示词中把验收标准写死“你没有运行过 pytest 之前禁止设置 completed 为 true。”“如果工作目录中没有生成对应的.py文件禁止设置 completed 为 true。”同时在代码层面校验可以在 completed 为 true 时额外检查工作目录中是否存在预期产物如果没有则忽略完成信号并强制模型继续。7.3 上下文长度超限项目文件多、上下文装配太激进是最常见原因。排查思路是看报错是 prompt 超限还是 history 超限。如果 prompt 超限缩短目录树深度、减少自动注入文件数量、增加单文件截断策略。如果 history 超限压缩历史消息比如只保留最近三轮对话加工具结果。引入摘要机制在对话轮数增加时把早期讨论摘要成一段简短的“已完成事项”注入到系统提示词。在模型 api 的入参里还可以开启自动截断但我不建议完全依赖它因为可能会把关键约束截掉。7.4 生成代码能跑但不符合项目规范这是“测试通过但质量差”的典型场景。测试只验证正确性验证不了风格。解决思路在提示词中注入项目的.editorconfig、flake8、mypy配置。在工具列表里增加run_lint工具用静态检查工具的结果作为反馈。引入评审模型弥补单一模型的视角盲区。7.5 Harness 循环陷入死循环模型来回修改代码但测试一直不通过直到达到 max_steps。应对措施设置最大迭代轮数避免无限消耗 token。每轮反馈中附带上一次错误信息避免模型重复犯同样的错。如果连续三轮输出相同的修改意图直接中断并生成失败报告。人工介入机制某个子任务失败次数过多时通知开发者手动处理。8. 最佳实践与工程建议8.1 从最小闭环开始不要一步到位很多团队设计 AI 编码 Harness 时容易过度设计一开始就上多智能体、向量数据库、复杂记忆系统。我的建议是先把“任务-生成-测试-反馈”这个最小闭环跑通然后把项目日常需求丢进去验证效果再逐步加能力。这样定位问题会容易很多。8.2 路径安全是不可妥协的底线无论模型多强工具调用边界必须由 Harness 强制约束。所有文件操作都要做路径规范化校验禁止访问工作区之外所有命令执行都要限制超时时间生产环境一定要使用容器或虚拟机隔离。安全不是可选项是使用 AI 生成代码的前提。8.3 提示词中的约束要“重复但不冗余”系统提示词里工具列表要说一次工具描述里要再说一次用户任务里可以再强调一次。模型对长上下文中的信息存在注意力衰减关键约束的适度重复能有效提升遵循率。但不要每轮都重复全部约束否则会占用上下文空间影响模型对任务信息的关注度。8.4 为模型提供可验证的验收标准可控性的核心来自可验证的验收标准。如果任务目标是“优化代码”模型永远不知道什么时候算完成如果目标是“修复 test_xxx.py 中的 3 个失败用例”模型就有了清晰终点。在实际业务中尽量把需求描述转换成可以自动验证的测试用例或检查规则。8.5 日志与审计Harness 运行过程往往不可完全预测必须记录完整的运行日志。建议至少记录以下信息模型输入输出的完整消息。每一步执行的工具和参数。工具返回结果。每次完成的耗时和 token 消耗。最终生成的代码产物。这样无论是排查模型行为异常还是统计成本都有据可依。同时建议对 Harness 的配置变更也做版本管理避免调参后无法回滚。8.6 权限与最小化原则生产系统里Harness 使用的 API Key 要独立于业务系统权限最小化只能访问模型服务不能访问数据库和其他内部系统。工作目录和 Git 仓库分离模型生成的内容先经过人工或 CI 检查再决定是否合并到主分支。涉及生产环境变更时必须先经过完整测试环境验证不允许 Harness 直接操作生产资源。9. 总结与下一步学习方向我在多个场景中反复验证单纯靠换更大参数的模型并不能让代码生成变得可控。真正起作用的是 Harness 工程把模型从“自由生成器”变成“受约束的任务求解器”并通过工具调用、测试反馈、结构化输出、沙箱执行这些外部机制将模型能力锁在可控范围内。本文从最基础的最小闭环出发给出了一套可以完整运行的 Python Harness 实现在此基础上又展开了评审-修改循环、仓库级上下文、多智能体协作、沙箱执行等生产级实践。你可以把这套代码拿回去改造先替换成团队自己的模型服务地址和工具列表再用真实需求压测逐步形成适合自己项目的 Harness 方案。下一步建议从这几个方向深入第一研究 Codex、DeepSeek Harness 等开源项目的代码实现参考它们在 Agent 循环、上下文压缩和工具设计上的细节第二学习 Prompt 工程中的高级方法比如示例选择、思维链、few-shot 设计这些能显著提升 Harness 内模型输出的稳定性第三关注测试生成和代码评审这两个方向这是让 Harness 具备“自校验能力”的关键闭环。代码生成的可控性没有终点模型能力会继续增强但 Harness 工程的价值不会减弱。因为越是强大的模型越需要清晰的边界和可靠的验收机制而这个边界恰恰是我们这些做工程的人最擅长的事。