感谢LLM时代
首先做一下基本的名词解释
名词解释
Agent 产品
├── 交互界面
├── 基座模型
└── Harness
├── Agent Loop
├── 上下文与记忆
├── 模型调用系统
├── 工具调用系统
└── 权限、沙箱与异常处理交互界面
界面是人机交互的的基础，人类怎么跟计算器交互，键盘鼠标麦克风等等是人类的输入器，界面有2个作用，一是标准化人类的输入，让人自己的输入所见即所得；二是返回机器的输出给人类。
GUI = Graphics User Interface，用户图形界面。比如大家用的Work buddy，Codex。互联网和移动互联网，几乎所有的产品都是通过GUI让用户使用。缺点是很多能力被封装在按钮和页面里，对Agent不友好，Agent只能使用Computer User调用，效率非常低。
CLI = 命令行界面，Command Line Interface。但是随着Agent流行，CLI多了一个延伸的变体含义，就是可以通过CLI便捷调用的服务，典型比如Toy CLI。如果有一个人跟你聊CLI，你要先搞清楚他想说的是前者还是后者。几个月前跟我司一个研发老大聊，他说万物皆CLI，我脑海里想到难用的命令行，面露难色。
TUI = GUI + CLI，Terminal User Interface，也有一种翻译是Text-based User Interface。最典型的就是Claude code，在终端里运行，但是也有一些图形化的交互。
大体上来说，TUI等于人类更友好的CLI，GUI对大多数非程序员更友好，CLI对AI更友好。
为什么界面需要对Agent更友好？因为你需要使用多个AI时，往往涉及到用一个Agent组织调度多个其他Agent，这个时候CLI的价值就凸显了。
模型
LLM，Large Language Model，大型语言模型，简称模型。
这几乎是AI行业唯一重要的东西。
大家常提到的模型比如：GPT、Claude、Gemini、DeepSeek、QWen。
当然，上面有一些模型，同时可能他们的对用户产品也用了同一个品牌名，使用的时候要注意区分。
同一家的模型，可能有很多不同的型号，就像手机有很多型号一样，同一家之内，在其他字段一样的情况下，数字越大代表越新，那大概率越强。
因为模型两个字听上去有点简单，很多人可能会说基座模型或者模型基座。
原教旨学术和研究界里，模型基座可能指的是只做过预训练，没有做过后训练（比如SFT、RLHF、DPO等）的模型，这里不展开。
模型大家可以理解为一个黑盒子，人类输入语言（token）进去，模型输出语言出来。
所谓的模型推理，就是基于上文预测下文的语言。
Harness
直译马具、挽具，也常被误传为缰绳。这是一个比喻，意思AI是马，人通过缰绳来驾驭马。
Harness比较复杂，广为人知的比如DeepSeek Harness。
Harness的定义还在混沌演化。
像DeepSeek团队对Harness的定义很激进，类似原教旨安卓，“Everything is a plugin”。
DSH只想提供最优秀的架构和最必不可少的组件，剩下的全都靠各种插件能力来实现。插件可能是自研的，也可能是开源社区共建的。
一遍来说，大家讨论的Harness，往往指的是某个具体的Agent产品里，除了界面和模型外，剩下的部分。
剩下的部分是什么呢？非常复杂。
Agent Loop + 上下文与记忆 + 模型调用系统 + 工具调用系统 + 权限与安全 + 任务状态与异常处理。
Agent Loop：让模型在“思考—行动—观察结果”之间不断循环；
普通聊天模型通常是“一问一答”：用户提问，模型生成一段文字，任务结束。
Agent 则需要反复执行一个循环：
理解任务 → 判断下一步 → 调用工具 → 查看结果 → 调整方案 → 继续执行。
这个循环什么时候开始、什么时候结束、什么时候需要向用户提问，以及卡住之后如何恢复，都是 Harness 要处理的问题。
上下文与记忆：管理任务信息、历史记录和长期记忆；
模型每次思考时，都需要知道用户的目标、之前做了什么、工具返回了什么，以及当前有哪些限制。
Harness 负责把这些信息组织成模型能够理解的上下文。上下文太长时，还要进行压缩、摘要或者淘汰。
有些 Harness 还会管理长期记忆，把用户偏好、项目知识和过去任务的经验保存下来，在未来的任务中继续使用。
可以把它理解成：模型负责思考，Harness 负责整理模型桌面上的资料。
模型调用：连接、切换和调度不同的基座模型；
Harness 还要负责真正调用基座模型，包括选择模型、组装请求、处理返回结果、计算上下文长度，以及在不同模型之间进行切换。
有些 Harness 只支持固定模型，有些则支持多个模型：简单任务交给便宜的小模型，复杂任务交给能力更强的模型，模型失败时还可以自动重试或者切换供应商。
因此，Harness 和模型不是绑定死的。同一套 Harness 可以连接不同模型，同一个模型也可以被放进不同 Harness。
工具调用：让模型使用 Shell、浏览器、文件和 MCP Server；
模型本身只能生成信息，不能真的打开浏览器、修改文件或者运行程序。
Harness 会把 Shell、浏览器、文件系统、数据库和 MCP Server 等能力包装成模型可以理解和调用的工具。模型判断“下一步应该搜索网页”，Harness 才会真正执行搜索，并把结果重新放回上下文。
需要注意，具体的浏览器、数据库和外部服务不一定属于 Harness，但工具的注册、调用、调度和结果回传系统通常属于 Harness。
可以把模型看成大脑，工具看成手脚，Harness 则是连接大脑和手脚的神经系统。
权限与安全：管理审批、沙箱和数据访问；
Agent 不只会说话，还可能修改文件、发送消息、执行代码，甚至操作线上系统。
因此，Harness 还需要决定哪些操作可以自动完成，哪些操作必须经过用户确认；工具应该在什么沙箱里运行；哪些文件和数据可以访问；危险操作应该如何拦截。
能力越强的 Agent，越需要一套可靠的权限系统。否则它不只是可能答错，还可能真的做错。
犹记得去年AI的Agent能力还不强的时候，我一个朋友的电脑被Agent顺手清楚了全部硬盘资料的惨案。
实际使用上，大家为了便利，往往会给Agent开全部权限。否则不停要进行无意义的授权，非常麻烦。
任务管理：支持暂停、恢复、重试、并行和后台运行。
一个复杂任务可能持续几十分钟甚至几个小时，中间还可能遇到网络失败、工具报错、模型超时或者用户暂时离开。
Harness 需要保存任务状态，让 Agent 可以暂停、恢复、重试和继续工作。有些 Harness 还支持并行任务、子 Agent、定时执行和后台运行。
Harness 并不是一个简单的模型外壳。它负责把一次模型调用，变成一个可以持续行动、观察结果、处理异常并最终交付成果的 Agent。
这也是为什么，同一个基座模型放进不同 Harness，使用体验和任务完成率可能相差很大。
模型决定一匹马有多聪明、能跑多快；Harness 决定它能不能听懂方向、跨过障碍，并最终把人送到目的地。
Tool、MCP和Skill
Tool：Agent 可以调用的一项具体能力。
搜索网页、读取文件、执行命令、查询数据库、发送邮件和生成图片，都可以是 Tool。
工具可以由 Harness 内置，也可以来自 CLI、API 或 MCP Server。基座模型负责判断应该使用什么工具，Harness 负责真正调用，并把结果交还给模型。
没有工具的 Agent，主要只能生成内容；拥有工具之后，它才能真正对外部世界采取行动。
MCP：Model Context Protocol，是 Agent 连接外部工具和数据的一种开放协议。
可以把它理解成 Agent 世界的 USB-C：以前每个 Agent 都要为不同服务单独开发接口，现在服务可以通过 MCP Server，用相对统一的方式向 Agent 提供能力。
MCP 本身不是工具。一个 MCP Server 可以同时提供多个 Tool，例如读取日历、创建日程和取消会议。
简单来说：
Tool 是电器，MCP 是插头标准，MCP Server 是插着一排电器的扩展坞。
对Agent来说，CLI和MCP非常类似。
Skill：更接近一份给 Agent 使用的说明书或者 SOP。
Tool 告诉 Agent“你能发邮件”，Skill 则告诉它“什么情况下应该发、发给谁、采用什么格式、发送前需要检查什么”。
一份 Skill 通常会描述：
什么情况下应该使用；应该按照哪些步骤执行；有哪些限制和注意事项；怎样判断任务已经完成。
有些 Skill 还会附带脚本、模板、参考资料和素材。它通常不会改变基座模型，而是在需要时为 Agent 提供更具体的工作方法。OpenAI 对 Skill 与 MCP Server 的说明
例如，让 Agent 写一份公司周报：
Tool：读取日历、查询任务系统、创建文档；
MCP：把日历和任务系统连接给 Agent；
Skill：规定周报的收集步骤、格式、语气和检查标准。
所以，一个最简单的记忆方式是：
Tool 是能力，MCP 是连接，Skill 是经验。
Skill本质就是一段渐进式披露的Prompt（提示词，文本）。
说到这里多提两句暴论。在立项做Toy的同时，我也考虑过是否做Skill hub，自己还手搓过原型。但后来的结论是不做。
因为Skill只有两头有价值，一个是超头部，覆盖面非常广的Skill，举例早期的web access，A社出的Frontend design，还有让新手使用Agent也能表达清楚需求的Superpowers。
这里且不提上面这类非常容易被Agent自身合并进自带能力，或者LLM训练时直接吞噬。
另一个则是广大中长尾，个人Skill。所有的Skill要想好用，大概率需要结合个人使用场景需求，进行一定程度的自定义。
因此不存在像AppStore一样的大量标准化的Skill，能形成事实上创作者消费者的匹配。
原生、个人和项目Harness
狭义来说，Harness指的是其研发者提供的全套包含代码、文本的产品，也就是用户下载到本地的东西。
但大模型很神奇，个人实际使用时，Agent也可能变得越来越好，或者说越来越符合某个用户本人的需求。
用户本人让Agent越来越好，这件事，就是用户自己的Harness。
而如果大家在一个团队里使用Agent，大概率需要协作，又涉及到项目Harness。
有效Harness = 原生Harness + 个人Harness + 项目Harness
原生 Harness
由 Agent 产品官方提供，决定产品的出厂能力，具体见上文不赘述。
Codex、Claude Code 和 DeepSeek Harness 的核心差异，主要存在于这一层。
个人 Harness
用户长期使用后沉淀出的个人配置，例如：
自己安装的 Skill；
常用的 MCP Server 和 CLI；
全局规则与个人偏好；
权限配置、模型选择和自动化流程；
反复打磨出来的提示词与工作方法。
它让一个通用 Agent 逐渐理解“我习惯怎样工作”。
之前有一些场合需要我去做分享，但是分享内容又很浅，我又非常忙没时间写分享课件。就会丢过Agent一句话直出 HTML 课件。效果马马虎能到70分。
有同事对这一切很惊讶，其实这就是我长期沉淀的个人Harness实现的效果。
Agent跟大多数古典软件工具产品完全不同，用得越多，真的就会越好用。
传统软件工具，如果是有算法驱动的搜推，可以有用得越多越爽的效果；又或者是存在平台和网络效应的内容平台和社区，也可能用得越多产品体验越好。
但如果是纯工具，比如视频编辑工具，体验的提升完全依赖用户个人使用能力的提升。
项目 Harness
围绕某个项目或者团队积累的工作环境，例如：
Codex 的 AGENTS.md、Claude Code 的 CLAUDE.md；
项目文档、架构说明和代码规范；
测试、Lint、构建脚本和 CI；
项目专用的 Skill、工具与操作手册。
它让 Agent 不只会使用工具，还知道“在这个项目里应该怎样工作”。
综上，个人 Harness 并不是另一套独立程序，更像覆盖在原生 Harness 之上的配置和能力层。
原生 Harness 决定 Agent 的出厂能力，个人与项目 Harness 决定它能否真正适应你。
使用 Agent 越久，真正有价值的沉淀往往不只是聊天记录，而是不断完善的规则、Skill、工具和工作流程。
Evals
Evaluations，评估机制的缩写。
对于Agent提供方来说，Evals很重要，能用来牵引优化Agent。
Evals也是个人使用Agent的最重要的一部分。
狭义上，Evals 不是 Harness 本身，而是用来评价 Harness、模型和 Skill 表现的测试系统。就像考试不属于学生，但考试能告诉我们学生学得怎么样。
广义上，Evals 可以成为个人 Harness 的质量控制层：
Tool 决定能做什么，Skill 规定怎样做，Evals 判断做得好不好。
Evals 主要有两种形态：
离线 Evals：准备一组典型任务和预期结果，用来比较不同模型、Harness、Skill 或提示词。它在任务之外运行，因此更像 Harness 的测试系统。
运行时 Evals：Agent 每完成一步就运行测试、Lint、格式检查或质量审查，再根据结果继续修改。它进入了 Agent Loop，因此可以视为 Harness 的一部分。
例如写文章时，个人 Evals 可以检查：
有没有事实错误；
是否符合自己的语言风格；
有没有重复和 AI 腔；
篇幅、结构是否符合要求；
引用是否可靠。
写代码时，测试、Lint、类型检查和构建结果，本质上都是很强的 Evals。当 Agent 根据这些结果不断修改代码时，Evals 就变成了它的反馈信号。
因此，更完整的表达可以是：
个人 Agent 系统
├── 个人 Harness
│ ├── 规则与偏好
│ ├── Skill
│ ├── MCP 与工具
│ └── 自动化工作流
└── 个人 Evals
├── 质量标准
├── 典型测试任务
└── 回归检查如果 Evals 只是用来定期考试，它在 Harness 外面；如果 Evals 的结果会直接驱动 Agent 继续行动，它就进入了有效 Harness。
我使用Agent的一些情况
一些过往
前两年试用过Cursor，浅尝辄止，做出来过一个上架了的微信小程序。但那时候模型的能力还不太行，更多局限于Coding领域。
后来去年年底到今年年初，使用谷歌的Antigravity，再后来谷歌拉跨了，换用Codex并长期使用，也试用过Claude code这种CLI，或者其他开源的Agent比如Cherry、Open Code等等。
值得一提的是，是从gemini开始，我大量使用 ChatBot 生成 HTML结果。这也是Toy起源的一个关键点。
一度同时开了Codex和Claude的20X包月会员。
后来，每当有一个新的水准之上的模型出来时，我也会试用一下，比如Kimi K3，QWen 3.8-max。
再后来黄老板的Cindy上线，被朋友安利去体验了一下。从此以后跟Codex一样成为我每天都用的产品。
Claude家的模型和Agent，只是浅尝辄止，因为A社对国人的不友好，服务难以稳定，我就不太敢用。
目前来说
日常主力Agent：ChatGPT 20X会员，然后本地使用Codex
备用Agent：
Cindy，接GPT的订阅调用Sol，或者接的阿里百炼的QWen 3.8-max的API，或者接DeepSeek官方的API。
Kimi，最贵档，名字太生僻了记不住，下个月就准备不续费了。虽然质量不错，但是又慢又贵，一个月的token，做不了多少事就没了。
模型
常规：Codex 5.6 Sol 极高｜标准速度
tibo快重置了：Codex 5.6 Sol 极高+ | 1.5x快速
次常规：QWen 3.8-max
最兜底：DeepSeek V4-pro
一些简单且需要快速对谈的任务：DeepSeek V4-flash
生图模型：GPT订阅自带的image-2，如果没了，考虑用gemini兜底
关于Cindy
最后尤其要提一下Cindy，Cindy Github地址。
除了很不错的审美，黄老板亲自蹬的更新速度以外，功能层面有2点非常值得推荐。
移动办公
如果你需要手机远程使用Agent，而此前没有好的解决办法，可以使用Cindy。
Codex内置的手机远程功能堪称一坨💩，延迟高，稳定性差。
而使用Cindy，你可以调用Codex Harness和GPT 5.6 Sol。爽的飞起。
Cindy = GUI层 + 协作Harness
Cindy自己并不自建完整Harness，但是它可以调用其他Harness，相当于在其他Harness上，增加一个更用户友好的GUI。
目前已经支持的Harness有Claude、Codex和Pi。
所以，你可以像我一样，使用Cindy调用Claude调用QWen 3.8-max。
Cindy真正自己自研的是协作Harness，就是如果某些任务，你如果自己原本就打算让多个Agent协作实现，Cindy围绕这个场景做了很多优化。
感谢看到这么久～欢迎交流～
请夸我就好，不用指出我的不足。生活已经如此艰难，我不需要花几个小时写的东西，被别人指出我的不足，谢谢：）
