1. Agent 系统的构成

Agent 系统常被理解成模型加界面。这个公式能解释聊天产品，解释不了长任务、工具调用和生产环境。

模型负责理解、推理和生成。上下文怎么装配、工具怎么调用、状态怎么恢复、权限怎么控制、结果怎么验证，这些都不由模型决定，要由模型之外的工程系统承担。

把这部分拆开，可以得到 7 层：

1. 缘起

写这篇文章的起因是大家对 harness 概念理解有 gap。
我说某系统的表现主要由 harness 决定，
对方问，是不是那个 AGENTS.md 文件。

这类定义错位不是个例。2026 年上半年的几篇公开文章视角不同：

• LangChain 讲组件清单，
• Anthropic 讲多角色闭环，
• OpenAI 讲执行环境改造。各家结论并不冲突，但缺少统一框架。

因此本文系统梳理一次：从最小组成推导，再逐层扩展，最后落到三类真实场景的选型。

1. 软件工程是什么

1.1 本质追问

软件工程不是「写代码」，也不是「写文档」。它的核心命题是：

如何在不确定性（需求会变、人员流动、技术演进）中，让一群人持续产出可维护、可交付的软件。

这个定义里有三个关键词：

• 不确定性：不是已知路径的复现，而是应对变化的能力
• 一群人：协作规模是关键变量。一个天才能搞定的事，十个天才不一定能搞定
• 持续：做出来不算完，还要持续交付、持续维护

1.2 软件 vs 传统工程的根本差异

1. 背景与连接

桌面上的音频系统是 Mac Studio、魅蓝 HD2 小尾巴，加一对漫步者 S3000MKII 书架音箱。

graph LR
    A["Mac Studio"] -->|Type-C| B["魅蓝 HD2 小尾巴"]
    B -->|"4.4mm 平衡输出"| C["4.4mm 转双 XLR 平衡线"]
    C -->|"XLR 左 / 右"| D["主箱 XLR 接口"]
    D -.->|"蓝牙"| E["副箱"]

Mac Studio 自带的 3.5mm 耳机孔也能出声，但和小尾巴差别不小：

• 设备定位：小尾巴是外置解码耳放；Mac Studio 内置的是一块集成音频接口。
• 音频芯片：小尾巴用双 CS43131 独立 DAC 芯片；Mac Studio 用苹果自研的集成音频 Codec。
• 输出接口：小尾巴有 4.4mm 平衡口和 3.5mm 单端；Mac Studio 只有 3.5mm 单端，支持高阻抗耳机自适应。
• 最高采样率：小尾巴支持 PCM 384kHz/32bit 和 DSD 256；Mac Studio 最高 PCM 96kHz/24bit。
• 抗干扰：小尾巴电路独立，供电和传输都在机箱外；Mac Studio 的耳机口在机箱内部，容易受主板和固态硬盘的高频信号影响。

对于 S3000MKII 音响，小尾巴比 Mac Studio 的耳机口更合适的地方有三处：

1. 概览

AI Coding 的关键是让模型在正确时间拿到正确上下文。
把散在文档、聊天记录、邮件和成员脑子里的细节归拢到一处，让模型按需使用。
这样才能早日实现 one-shot 开发( 许愿式开发 / 一句话需求 )。

这份指南覆盖四个阶段：

• 新项目：搭上下文底座。
• 老项目：补齐代码读不出的约束。
• 日常需求：沉淀和复用上下文。
• 团队：把方法变成可维护的工程约束。

适合正在用 Coding Agent 的工程师和技术负责人。全文偏操作。
新项目从第 2 节读起，老项目从第 3 节读起，日常需求看第 4 节，团队推广看第 5 节，长期维护看第 6 节。

先从 Agent 的入口文件开始。
AGENTS.md ( Agent 主流入口，cc 也支持了 )是 Agent 的地图，只回答「去哪里找」和「什么时候看」：

短信不算笔记，但同样是散在外面的一份记录。既然要把这些东西收敛到本地，便签之外顺手把它也拿下来。脚本在 GitHub 上：phone-cloud-data-export/flyme-sms。

魅族云的短信备份页面还在，地址 cloud.flyme.cn/browser/sms-list.jsp。我账号里 1595 个会话、7600 条消息，最早一条是 2007 年，最后一条停在 2022 年初。

网页版没有批量导出，只能一页页翻。这篇和魅族云便签、锤子便签是同一批，都用浏览器里跑脚本的办法把数据拿下来，再在本地转成 CSV 和 Markdown。

笔记散在好几个地方，魅族便签是攒得最多的一处。这轮的打算是把它们收敛到本地一个目录，来龙去脉写在锤子便签那篇里。脚本在 GitHub 上：phone-cloud-data-export/flyme-notes。

魅族云便签的网页版在 notes.flyme.cn。我账号里 605 条笔记，时间从 2014 年排到 2022 年，多数是当年在地铁上用手机随手记的。

这套导出也分两步：先在已经登录的页面里跑脚本抓原始 JSON，再在本地转成带 frontmatter 的 Markdown。Cookie 不出本机。

我的笔记一直散着。读书时记的放锤子便签，通勤路上随手写的放魅族便签，早年还有有道云笔记和 Notion。时间一长，自己都说不清哪条在哪儿，搜也搜不全。知识管理与消费里问过一句，散落各处的笔记、随想能不能有个地方统一管起来；工作的第一个十年里也提过，说想把所有数据整合到一起。

想把它们收敛到本地一个目录、用自己的方式管起来，就得先把每个来源的数据拿下来。锤子便签是其中一份，另外两份是魅族云便签和魅族云短信。脚本都开在 GitHub 上：phone-cloud-data-export/smartisan-notes，拿到就能跑。

锤子便签的云端在欢喜云 yun.smartisan.com。手机端早就停更，账号中心跳去了 snote.ink，那是字节接手后的另一套产品，和原来的便签不是同一份数据。

我账号里还有 370 条便签挂在旧接口上。产品在收缩，接口没有退场说明，能拿的时候先拿。导出分两步：抓原始 JSON，再转成带 frontmatter 的 Markdown。

DHH 在 Rails World 2026 上说，37signals 已经不再把手写代码当成正常业务。八个多月前，也就是 2026 年 1 月，他还在文章里写，自己做不到 90% 以上代码由 agent 写。

他现在维护 Omarchy，一个把 agent 接到系统里的 Linux 发行版。

我写过《AI 替代的是任务，不是程序员》，那篇讲被替代的是什么。这篇讲另一半：外包之后，资深工程师和架构师该留下什么。

具体实现和重复的操作可以交给 AI。质量、安全、合规和长期系统不行。架构师的新职责是决定哪些地方永远不能交出去。

程序员会不会被 AI 取代，这个问题被反复问了好几年。真到了日常的工作里，被替掉的是一部分任务：样板代码、重复修复、机械实现。审查、验收和判断留了下来，它们的成本并没有下降。

软件工程攒了几十年的实践，比如完整的回归测试、跟随代码演进的文档、清晰的模块边界和性能基准，一直没有真正普及。它们对人力的消耗太大，有交付压力时总是先被砍掉。AI 把执行成本降下来之后，这些实践第一次变得划算。