1. AI原生开发入门:核心概念解析
作为一名长期从事AI应用开发的工程师,我经常遇到这样的场景:当我把一个功能需求交给AI助手时,它能够快速生成200行代码,但在执行lint检查时却失败了。随后它开始尝试修复:移动文件、调整依赖、重新组织代码结构。然而每次重新运行都会出现新的问题,经过三次循环后,上下文窗口已经被错误日志塞满,AI助手开始"忘记"最初的任务目标。这不是AI不够聪明,而是它缺乏对开发环境的完整"视野"。
在这篇文章中,我将从四个核心概念出发:大模型(LLM)、智能体(Agent)、技能(Skill)和指令(Command),逐步拆解AI原生开发的底层逻辑。同时结合我在Harness工程中的实践经验,分享一套让AI协作真正可靠、可复用且能自我进化的完整方案。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 大模型:AI协作的"推理引擎"
2.1 大模型的核心能力
大模型(Large Language Model,LLM)是整个AI原生开发体系的核心能力来源。它不是一个简单的问答系统,而是通过对海量文本的深度学习,掌握了语言理解、逻辑推理、代码生成、指令遵循等综合能力的神经网络。
在实际开发中,大模型主要展现以下能力:
- 代码生成:根据自然语言描述生成符合语法的代码
- 代码补全:基于上下文预测并补全代码片段
- 错误诊断:分析代码错误并提供修复建议
- 文档生成:从代码自动生成说明文档
- 代码重构:优化现有代码结构和性能
2.2 大模型的局限性
理解大模型的局限性同样重要。在我的实践中发现,大模型存在以下几个关键限制:
- 知识时效性:模型的"知识"截止于训练数据时间点,无法自动获取最新技术动态
- 项目特定知识缺失:不知道你的内部架构约定、文件目录规范或禁止使用的import
- 上下文窗口限制:随着对话进行,早期关键信息容易被"遗忘"
- 确定性不足:相同输入可能产生不同输出,不利于构建稳定流程
用计算机架构来类比:LLM就像强大的CPU——具备极强的推理能力,但没有"操作系统"的支持,它不知道硬盘在哪、哪些内存地址可以写入。而Agent与Harness的组合就是为它提供的那个"操作系统"。
3. 智能体(Agent):会"行动"的AI
3.1 Agent的核心架构
如果说大模型是大脑,那么智能体(Agent)就是能够感知环境、制定计划、调用工具、执行任务的"完整个体"。它的核心差异在于:不止是"回答"问题,而是能够"行动"。
一个完整的Agent通常包含五层结构:
code复制感知层 → 大模型(LLM) → 规划层
↕ ↕ ↕
记忆层 ←←←←← 工具层 →→→→→ 执行层
- 感知层:接收用户输入、文件内容、工具输出,构建当前上下文
- 记忆层:分为短期记忆(当前对话上下文)和长期记忆(跨会话的项目知识)
- 规划层:使用链式思考(Chain of Thought)将复杂目标分解为可执行步骤
- 工具层:调用外部能力如代码执行、Web搜索、文件读写等
- 执行层:将规划转化为具体操作并反馈结果
3.2 Agent与LLM的关键区别
在实际项目中,我发现Agent与单纯使用LLM有几个显著区别:
- 状态保持:Agent可以维护对话状态和项目上下文
- 工具集成:能够调用外部工具和API扩展能力
- 自主迭代:可以根据执行结果调整策略
- 记忆能力:保留历史交互和项目特定知识
例如,在开发一个用户认证模块时,普通LLM只能单次响应代码片段,而Agent可以:
- 读取现有代码库
- 分析架构约束
- 分步骤实现功能
- 运行测试并修复问题
- 记录解决方案供未来参考
4. 技能(Skill):可复用的"能力模块"
4.1 Skill的类型与价值
如果把Agent比作工程师,那么技能(Skill)就是他工具箱里的专业工具。Skill是对特定能力的封装与复用单元,实现"一次开发,多处使用"。
在我的项目中,通常将Skill分为四大类型:
-
代码技能:
- 代码生成:根据描述生成功能代码
- 代码审查:检查代码质量和规范
- 重构优化:改进代码结构和性能
- 测试编写:生成单元测试和集成测试
-
工具技能:
- 文件操作:读写和修改文件
- API调用:与外部服务交互
- 数据处理:转换和分析数据
- 系统命令:执行Shell命令
-
搜索技能:
- Web检索:从互联网获取信息
- 代码检索:在项目中查找代码
- 文档查询:搜索技术文档
-
协作技能:
- 任务委派:分配子任务给其他Agent
- 结果汇总:合并多个Agent的输出
- 状态同步:保持团队信息一致
4.2 Skill的标准结构
一个良好设计的Skill应遵循标准结构:
yaml复制---
allowed-tools: Bash, Read, Write, Edit, Grep
description: 描述这个Skill能做什么,触发条件是什么
argument-hint: "[--option1 <value>] [--option2 <value>]"
---
# Skill名称
## 执行逻辑
1. 输入解析
2. 核心处理
3. 输出格式化
Skill的核心价值在于:
- 一致性:同一能力在不同场景表现一致
- 可测试性:可以单独验证正确性
- 可组合性:多个Skill串联构建复杂流程
- 可进化性:优化一个Skill,所有使用者受益
例如,我们开发的doc self-evolve是一个复合Skill,它内部编排了:
- 风格学习:分析项目文档风格
- Writer创作:生成初稿
- Reviewer评分:质量评估
通过Writer-Reviewer双Agent迭代,以85/100为目标分数,最多3轮收敛。
5. 指令(Command):用户意图的"结构化语言"
5.1 Command的形态与作用
指令(Command)是用户与AI协作体系之间的标准接口。它将模糊的"做这个"转化为精确的、参数化的执行指令,让Agent明确"做什么、怎么做、达到什么标准"。
在实际系统中,Command通常有三种形态:
- Slash命令(Slash Command):
bash复制/doc self-evolve --title "AI开发指南" --target-score 90
/commit --message "feat: 添加验证管道"
/review --type security --file src/auth.ts
- CLI参数化指令:
bash复制python3 scripts/verify_action.py --action "创建文件internal/types/user.go"
# ✓ 有效: internal/types/是第0层,user.go符合命名约定
python3 scripts/verify_action.py --action "从internal/handler导入internal/core"
# ✗ 无效: handler(L4)不能直接导入core(L3)
# 修复: handler应通过接口依赖core
- 自然语言指令(配合意图解析):
code复制"帮我审查auth模块的安全性,重点检查token存储方式"
"将用户认证逻辑重构成符合分层架构的形式"
5.2 Command的执行链路与设计原则
Command的标准执行链路如下:
code复制用户输入 → 指令解析 → Skill加载 → Agent执行 → 结果验证 → 输出返回
↑_________|(验证失败重试)
设计良好的Command应遵循以下原则:
- 参数明确无歧义
- 有明确的完成标准(验收条件)
- 支持错误时的优雅降级
- 错误信息足够清晰,能指导修正
6. Harness工程:构建可靠的AI协作系统
6.1 核心思想:仓库即操作系统
传统方法是教AI"怎么做"——编写更好的Prompt,提供更多示例。但这种方法存在天花板:规则会随代码演进变化,人工维护成本高。
Harness工程采用不同思路:与其教Agent怎么做,不如让它自己验证做得对不对。
对比两种思路:
code复制教学思路(有上限): 写更好的Prompt → 提供更多示例 → 规则文档 → ...
Harness思路(无上限): 代码 + linter + 测试 → 自动验证 → 拦截问题
6.2 Harness的五层架构
-
仓库即事实来源:
- AGENTS.md:导航地图(约100行),提供索引和指引
- docs/:架构文档、分层规则、业务上下文
- 知识随代码版本化,Agent打开项目即获取完整上下文
-
结构化知识体系:
- ARCHITECTURE.md:层级约束(Layer 0 → Layer 4+),依赖方向规则
- DEVELOPMENT.md:构建/测试/lint命令速查
- design-docs/:组件级设计文档,按需加载
-
机械化验证层:
- 验证顺序:build → lint-arch → test → verify
- 逐层递进,编译不通过就停止后续步骤
-
多Agent编排层:
- 协调者:负责任务分解和分配
- 执行者:专注具体子任务实现
- 评审者:验证结果质量
-
自进化学习层:
- 从成功和失败中提取经验
- 将重复模式编译为确定性脚本
- 持续优化验证规则和流程
7. 多Agent协作策略
7.1 上下文管理挑战
单Agent处理复杂任务时,上下文窗口会被代码diff、编译错误、lint报告逐渐填满。经过40次工具调用后,早期关键决策可能被压缩丢失,导致Agent做出自相矛盾的修改。
解决方案是采用两层架构:协调者负责任务分解,执行者专注具体实现,协调者自身不直接编写代码。
7.2 协调者与执行者分工
code复制协调者 vs 执行者
协调者:
- 任务分解与规划
- 上下文管理
- 结果汇总
- 不直接编写代码
执行者:
- 接收明确子任务
- 使用干净上下文
- 专注具体实现
- 返回结构化结果
7.3 任务复杂度与执行策略
根据任务复杂度选择合适的执行策略:
-
简单修改(如修复typo、添加日志):
- 直接执行(1次对话完成)
-
多文件一致性修改:
- 委派子代理(使用干净上下文)
-
重构或新模块开发:
- 子代理 + Worktree隔离环境
判断法则:
- 能用一句话描述且不含"和"字的:直接执行
- 需要清单跟踪的:委派子任务
- 需要设计权衡的:委派+隔离环境
7.4 模型分级调用策略
为优化成本,可以根据任务复杂度选择不同规模的模型:
python复制# 简单任务,轻量模型
Agent(description="重命名用户字段", model="haiku", prompt="...")
# 复杂任务,重量级模型+隔离执行
Agent(description="重构认证模块", model="opus",
isolation="worktree", prompt="...")
# 交叉评审,使用不同架构模型
review_result = Agent(description="评审:限流器", model="codex",
prompt=f"评审逻辑正确性、边界情况、命名...\n变更:{diff}")
通过这种分级策略,在开发中等复杂功能时(如搜索Agent检索代码 + 编码Agent实现 + 评审Agent审查),总成本可比全用顶级模型降低60-70%,而质量不受影响。
8. Harness自进化机制
8.1 三种记忆机制
静态的Harness规则会随着项目发展而过时。真正的价值在于让Harness能从Agent的失败中学习:
-
情景记忆:记录具体教训
- "macOS下/var是/private/var的符号链接,会导致路径比较失败"
- 保存这类知识可避免重复错误
-
程序记忆:记录成功步骤
- "添加API端点的标准五步流程,成功率90%"
- 将验证过的流程标准化
-
失败记忆:供分析改进
- 同类错误出现3次以上 → 分析根因
- 更新lint规则 → 预防未来错误
8.2 轨迹编译与棘轮效应
当同一类任务被成功执行3次以上,且步骤高度一致时,可以将这个模式"编译"成确定性脚本:
bash复制# 之前:每次都需要LLM推理
Agent("添加API端点NAME=UserProfile") # 消耗Token和时间
# 编译后:直接执行脚本
make add-endpoint NAME=UserProfile # 毫秒级,零LLM成本
这种"棘轮效应"使系统运行成本越来越低,能力越来越强:
- 成功模式变成永久基础设施
- LLM被释放去处理真正需要创造力的新问题
- 系统整体效率持续提升
9. 核心概念的协作关系
将大模型、Agent、Skill和Command的关系可视化:
code复制用户
│
▼
Command(结构化指令)
│
▼
Agent(协调与执行)
│
├─▶ Skill(能力模块)
│ ├─▶ 代码技能
│ ├─▶ 工具技能
│ ├─▶ 搜索技能
│ └─▶ 协作技能
│
└─▶ 大模型(推理引擎)
简而言之:
- 大模型提供推理能力
- Skill封装复用这些能力
- Command触发特定工作流
- Agent自主协调完成任务
在Harness工程中,这四者被整合成可靠、可复用、自我进化的AI协作系统。
10. 实践路线图
10.1 三步实施路径
根据项目规模和阶段,可以采用渐进式实施策略:
第一步(立竿见影):编写AGENTS.md
- 约100行,提供索引和指引
- 包含:架构层级规则、目录结构说明、常用命令
- 效果:新会话不再需要重复解释背景
第二步(构建护栏):添加lint脚本
- lint-deps:检查import层级违反
- lint-quality:验证文件行数、禁用语句等
- 关键:错误信息要清晰说明违反了什么、为什么、如何修
第三步(验证闭环):接入validate.py
- 统一验证入口:build → lint-arch → test → verify
- verify脚本应覆盖核心用户路径,而不仅是单元测试
10.2 不同规模项目的策略
-
个人项目:
- 轻量级Harness
- 基础验证规则
- 单Agent工作流
-
团队项目:
- 完整Harness
- 多Agent协作
- 自动化知识更新
-
企业级项目:
- 分层Harness
- 模型分级调用
- 自进化基础设施
11. 开发理念的转变
AI原生开发不是简单"用AI写代码",而是重新思考人与AI在工程体系中的角色:
-
开发者角色转变:
- 从"写出正确代码" → "设计让AI可靠产出正确代码的环境"
-
大模型定位:
- 是强大的推理引擎,而非万能答案机
- 需要"操作系统"支持才能发挥最大价值
-
系统演进方向:
- 棘轮效应:每次执行都在强化系统
- 每次失败都在产生学习
- 越使用越智能可靠
最终,你不再需要亲自拧每一颗螺丝,但要确保整个"流水线"设计正确。这正是AI原生开发的核心价值所在。
