一句话结论：AI 工程的重心，已从「如何让模型答得对」转向「如何让系统把任务做成、做稳、做闭环」。四层工程不是替代关系，而是从输入控制 → 信息供给 → 受控执行 → 反馈闭环的能力叠加；真正的瓶颈不是模型能力，而是上下文与执行环境。
01 · 四大工程：怎么问 / 看什么 / 在什么环境工作 / 下一步怎么办
Prompt Engineering
怎么问
把模糊意图变成可执行任务
指令 · 约束 · 示例 · 输出协议
Context Engineering
让 AI 看到什么
正确、可信、可追溯的信息
检索 · 窗口 · 记忆 · 引用
Harness Engineering
在什么环境工作
安全、可靠、可控地行动
工具 · 权限沙箱 · 验证 · 日志
Loop Engineering
做完一步怎么办
观察 · 评估 · 重试 · 收敛
人设计循环，循环驱动智能体
缺一不可（报告反例）
只有 Prompt，缺事实任务清楚但可能编造或片面 只有 Context，不会行动资料丰富但无法解决问题 只有 Harness，缺目标能调工具但不知做什么 只有 Loop，易空转反复迭代但不收敛
02 · 总览与四层演进
P04 · AI 工程四层演进：从单次被动响应到可运行·可验证·可交付的任务系统
P06 · 四层协作关系与缺一不可反例
P03 · AI 工程关注重点：从生成答案到闭环执行（资料检索 → 工具调用 → 验证结果 → 反馈调整 → 交付产物 → 持续迭代）
03 · Prompt Engineering 要点
P09 · 提示基本结构：身份/任务/上下文/约束/输出 + 验收标准/不确定性处理/引用要求
P14 · Prompt 工程化：仓库 → 草稿 → 离线评测 → 灰度 → 监控 → 回滚；可版本化·可评测·可回滚
Few-Shot用少量示例立标准 CoT 思维链多步推理逐步推导 Self-Consistency多路径采样投票 角色/受众/场景同任务不同输出结构 边界无法超越模型能力上限
04 · Context Engineering 要点
P16 · Context：多源信息 → 检索/筛选/排序/压缩/权限过滤/引用绑定 → 上下文包（去噪·保真·控权）
P19 · RAG：离线索引（采集/清洗切分/向量化/索引库）+ 在线推理（改写/召回/Rerank/拼装/生成/引用）
P20 · Naive RAG（固定流程单轮检索） vs Agentic RAG（动态编排多轮检索+证据判断）
关键结论：窗口变长 ≠ 信息质量变高。上下文是"有限预算"，需保留/裁剪/摘要/刷新/按需检索；记忆分三层：短期上下文（工作内存）、任务状态、长期记忆。
05 · Harness Engineering：系统的安全护栏（本报告最重章节）
P28 · Harness 七层架构 ETCLOVG：运行底座（E/T/C/L）+ 全局管控平面（O/V/G）
| 层 | 模块 | 要点 |
|---|---|---|
| E Execution | 核心运行底座 （身体与行动） | 执行环境与沙箱：隔离/可复现/提自主性；主流 E2B |
| T Tool | 工具接口与协议：精简精准工具集远优于大而全 | |
| C Context | 三级记忆；上下文衰减（窗口未满性能下降）、上下文漂移（长跑偏离目标） | |
| L Lifecycle | 生命周期与编排：单智能体/多智能体/流水线；有状态 vs 无状态权衡 | |
| O Observability | 全局管控平面 （大脑与风控） | 链路追踪、成本性能监控、故障运维 |
| V Verification | 五阶段闭环质检；Agent 分数 = 模型 + Harness 共同作用 | |
| G Governance | 权限/审计/防御/合规；安全是开源最薄弱环节 |
三大核心取舍
① 成本-质量-速度三元悖论ToB 优先质量，C 端优先速度与成本 ② 能力与管控此消彼长能力越强管控越难 ③ 层间耦合局部优化 ≠ 全局最优，需全链路测试
P36 · 成本-质量-速度三元悖论
P39 · 五大技术难题：环境加固、状态一致性、链路故障诊断、跨角色交接、随模型迭代动态简化
06 · Loop Engineering：循环的设计与自主执行
P41 · 过去：人不断驱动智能体；现在：人设计循环，循环驱动智能体
P43 · Loop 六大组件总览
| 组件 | 作用 |
|---|---|
| 1. Automations 自动化机制 | 循环持续运行的心跳：定时触发、扫描状态、总结失败 |
| 2. Worktrees | 并行协作隔离：同一仓库拆独立目录/分支，防文件覆盖与代码冲突 |
| 3. Skills | 知识沉淀底座：项目规范/构建/踩坑写入 SKILL.md，循环自动复用 |
| 4. Plugins & Connectors（MCP） | 连接真实工具：GitHub/Slack/数据库/CI/API |
| 5. Sub-Agents | 执行与验证分离：避免"既当运动员又当裁判"的自审盲区 |
| 6. Memory | 外部持久化记忆：状态写入磁盘，记录完成/失败/待处理，断点恢复 |
07 · 演进路径：三次范式跃迁
P52 · 指令驱动（Prompt）→ 信息驱动（Context+Harness）→ 系统驱动（Loop）
08 · 与行途（xingtu）体系的对照
这份报告描述的「AI 驱动研发体系 / 项目 Harness」模型，与 xingtu 当前的开源仓库矩阵高度同构。与其说是学到新概念，不如说是验证了我们已经走的方向，并补上了缺位。
项目 Harness（本地优先：Agent+文件夹+Git）
xingtu-harness / xingtu-cli
规则/技能/MCP/工具/SDD/钩子聚合为一个工作区整体
规则与决策边界（AGENTS.md）
xingtu-rules
分层规则 rules / rules-scoped / SELF.md
领域能力 skills/
xingtu-skills
Skill 组织一类任务，已能力市场化（marketplace.json）
门禁 scripts/
xingtu-hooks + xingtu-cli
把不能靠语言自觉保证的门禁执行到底
MCP 连接器
xingtu-mcps
Loop 组件 4：连接真实工具/环境
机器可读迭代协议（REQ/AC/TC）
xingtu-sdd
Spec-Driven Development：PRD→方案→测试固定串联
知识层 wiki/ + 知识飞轮
xingtu-vault
Raw→Wiki→Schema 三层编译 + 双链/MOC/来源必录
方法论与哲学
xingtu-ai-engineering
philosophy / methodology / governance
内容与传播输出端
articles / book / video / site / github-io
知识飞轮对外输出：文章、书、视频、站点、作品集
专用工具适配
xingtu-tools
Harness 工具层的精细适配
报告给我们补的位（差距 → 可落地动作）
| 差距 | 报告依据 | 行途动作 |
|---|---|---|
| 动态事实验证不足 | 测试必须绑定真实环境，回填 traceId 与断言；接口成功 ≠ 业务完成 | SDD 补"验收必须可执行验证"门禁，人工验证显式标注 |
| 发布完成标准未固化 | 合入主干 + 状态一致 + 证据齐全才视为迭代结束 | hooks/CLI 增加发布完成三要素校验 |
| 观测与成本较弱 | O 层：链路追踪、Token 成本统计 | 工具链增加单次任务 Token/成本回执 |
| 循环自动化仍是雏形 | Loop 组件 1：Automations + 状态文件 | 沉淀"定时触发+状态落盘+失败总结"模板 |
| Worktree 并行隔离未显式使用 | Loop 组件 2 | 多 Agent 并行时启用 worktree 分支隔离 |
| 验证与执行分离可强化 | Loop 组件 5：Sub-Agents 执行/审查分离 | 写代码与验收用不同角色/会话执行 |
09 · 我们的核心判断
1. Context 是第一性瓶颈 —— 谁的上下文资产厚、维护得好，谁的 Agent 就靠谱。
2. Harness 会收缩但不会消失 —— 业务知识治理、规则边界、领域工具、验证标准这四块"不会消失"的，正是行途在沉淀的部分。
3. 业务技术人更接近 FDE —— 核心价值 = 业务理解 + 系统连接 + 端到端结果责任。
4. 质量底线是"可验证"不是"看起来对" —— 任何自动化都要绑定真实环境证据回收。
5. 知识飞轮 = 行途护城河 —— 报告把知识飞轮讲成框架，我们已在跑真实闭环。
2. Harness 会收缩但不会消失 —— 业务知识治理、规则边界、领域工具、验证标准这四块"不会消失"的，正是行途在沉淀的部分。
3. 业务技术人更接近 FDE —— 核心价值 = 业务理解 + 系统连接 + 端到端结果责任。
4. 质量底线是"可验证"不是"看起来对" —— 任何自动化都要绑定真实环境证据回收。
5. 知识飞轮 = 行途护城河 —— 报告把知识飞轮讲成框架，我们已在跑真实闭环。