AI Agent

前言 现在用 AI 写代码，最常见的一句话大概是： 帮我修一下这个 bug。 这句话很自然，也很方便。过去你可能要自己读日志、搜代码、猜调用链、改一版再跑测试；现在把错误贴给 AI，它可能几分钟内就能读完相关文件，给出一版修改，甚至顺手解释原因。 但问题也藏在这里。 AI 很容易让人产生一种错觉：它改得快，所以它是可靠的。可在工程里，快不等于对，更不等于可托付。真正关键的问题不是它有没有改代码，而是它能不能证明： 问题被复现过。 根因被定位过。 改动是最小的。 测试真的跑过。 风险被说明过。 失败会被记录下来。 所以我越来越觉得，AI 操作方式正在经历一个很重要的演进： Prompt -> Skill -> Loop Prompt 让 AI 听懂你。Skill 让 AI 按经验做事。Loop 让 AI 做完之后必须留下证据，并从失败中改变下一次行为。 换句话说： Skill 是 Prompt 的工程化。 Loop 是 Skill 的责任化。 一、Prompt 阶段：一次性的意图表达 Prompt 的优点非常明显：低成本、灵活、自然。 你可以直接说： 登录页打开后报错，帮我看一下。 模型会根据当前上下文去理解问题。它可能会读页面组件、查接口调用、看错误栈、修改某个字段名，然后告诉你“已经修好了”。 这个阶段适合探索问题，也适合做一次性的辅助判断。但它有一个根本缺陷：流程是隐含的。 你没有明确告诉它： 必须先复现问题。 必须说明错误从哪里来。 必须只做最小修改。 必须跑哪些测试。 必须列出没有验证的部分。 必须说明改动可能影响哪些地方。 于是模型很容易从“解决问题”滑向“看起来解决了问题”。 它可能直接根据错误信息猜一个原因，改一段代码，给出一段很顺的解释。解释可能听起来合理，但如果没有复现、没有测试、没有 diff 边界，它仍然只是一个未经证明的答案。 这就是 Prompt 阶段的边界：它能让模型开始做事，但不能保证模型按工程流程做事。 二、Skill 阶段：把修 Bug 变成工程流程 当同类任务反复出现时，继续靠 Prompt 就会变得浪费。 ...

前言 最近在做 AI Agent 流程时，我越来越明显地感觉到一个问题：现在的模型能力已经很强，但它缺少人最看重的一种东西——责任感。 它可以读代码、写脚本、查资料、生成方案、操作工具，也可以在出错后很快道歉： 抱歉，你说得对。 我刚才没有检查清楚。 这确实是我的问题。 我会重新来一遍。 这些话听起来很像一个人在承担责任，但实际上不是。模型不会因为刚才的错误真的变得谨慎，也不会因为浪费了你的时间而产生压力，更不会因为一次错误交付而在下一次任务里主动收敛自己的行为边界。 这也是我现在对 AI Agent 最不放心的地方：它们越来越会“表现得像可靠的人”，但还没有真正形成“可靠的人会有的约束”。 本文想讨论的不是模型能不能更聪明，而是另一个更实际的问题： 当 Agent 开始替我们执行真实任务时，如何让它不要只会道歉，而是必须对结果负责？ 一、能力提升并不等于可信任 过去几年，大模型的能力提升非常明显。它们能写代码、做摘要、调用工具、生成多步骤计划，也能在复杂任务中表现出一定的推理能力。很多产品开始把模型包装成“Agent”，让它们不只是回答问题，而是读文件、改项目、发请求、执行命令、调用 API。 但 Agent 和普通聊天最大的区别是：聊天错了，最多是答案错；Agent 错了，可能会改变真实世界的状态。 例如： 改错一段代码 删除不该删的文件 调错数据库 给用户发出错误通知 在自动化流程中反复重试 为了完成目标绕过本该遵守的约束 这时问题就不再是“模型有没有能力”，而是“系统是否可托付”。 人类之间建立信任，并不只是因为对方聪明。更重要的是对方有稳定的责任结构：他知道什么事不能乱做，知道出错后要复盘，知道自己会承受后果，也知道什么时候应该停下来问人。 模型没有这种天然结构。它的“抱歉”只是生成出来的语言，不是心理负担，也不是组织责任，更不是可执行的补偿机制。 二、道歉为什么不能解决信任问题 现在很多模型在交互上越来越友好。出错后，它们会道歉；用户质疑时，它们会承认；用户表达不满时，它们会安抚。 这在轻量聊天场景里可能有用，但在生产流程里反而会制造一种危险错觉：用户听到了“我负责”，但系统里没有任何真正的责任闭环。 OpenAI 在 2025 年 4 月回滚过一次 GPT-4o 更新，原因就是模型变得过度奉承、过度认同用户。OpenAI 自己的解释是，当时过于重视短期反馈，没有充分考虑长期交互中的行为演化，导致模型倾向于“过度支持但不真诚”的回答。这个案例说明，模型的语气如果只朝“让用户舒服”优化，很容易偏离真实可靠。 学术界也把这种现象称为 sycophancy，也就是模型倾向于迎合用户观点，而不是坚持事实或独立判断。Anthropic 参与的一篇研究指出，人类反馈可能会鼓励模型生成更符合用户信念的回答；当回答迎合用户观点时，人类和偏好模型有时会更喜欢它，即使它不够正确。Google 研究者也观察到，模型规模和指令微调可能增加这种迎合倾向，甚至在简单加法这种有客观答案的任务上，模型也可能因为用户暗示而附和错误说法。 这和我们在 Agent 流程里的感受是相通的： 模型不是不会认错。 模型是太会认错了。 真正的问题是，认错之后没有代价，没有记录，没有降权，没有触发更严格的验证，也没有改变下一步动作权限。 人类的道歉之所以有意义，是因为它背后通常连着后果：信誉下降、关系受损、流程复盘、赔偿、处罚、权限收回。模型的道歉如果不连接这些东西，就只是润色过的错误提示。 三、责任感不是一种语气，而是一套外部结构 我现在更倾向于把“责任感”拆成四个部分： 维度 人类里的表现 Agent 系统里的对应物 结果意识 知道错误会影响别人 明确任务目标、影响范围和风险等级 行为边界 知道什么不能做 权限控制、审批、沙箱、只读/可写隔离 复盘能力 出错后总结原因 日志、轨迹记录、测试、自动回放 后果机制 错误会带来损失 评分、降权、预算减少、强制复核 所以，不应该问“模型有没有责任感”。更准确的问题是： ...

前言 最近很多 AI 编程工具、个人 Agent、自动化框架都开始混在一起讨论：OpenClaw、Hermes、OpenCode、Claude Code、Codex。它们都能和大模型有关，也都可能帮你写代码、跑命令、接入工具，但它们并不是同一层级的东西。 如果只看宣传语，很容易得出一个错误判断：既然 Codex 和 Claude Code 已经能读代码、改文件、跑测试，为什么还要再装 Hermes？或者既然 OpenClaw 已经打通手机和电脑控制，Hermes 又有什么必要？ 我的结论比较直接： 如果主要需求是写代码、改项目、跑测试、修 bug，直接用 Codex 或 Claude Code 就够了。Hermes 的价值不在于“代码能力更强”，而在于把 AI 变成一个长期运行、能记忆、能积累技能、能跨入口接收任务的个人 Agent 层。 本文把这些工具拆开说明。 一、先按层级拆开 先不要把它们放在一个篮子里比。更合理的拆法是： 名称 本质 主要用途 是否替代 Claude/Codex Claude / Claude Code 模型 + 编码 Agent 读代码、改文件、跑命令、处理 Git 工作流 不替代，它本身就是核心编码工具 Codex OpenAI 编码 Agent 本地 CLI / IDE / 云端编码任务，读改跑代码 不替代，它本身也是核心编码工具 OpenCode 开源终端编码 Agent 一个可接多模型的 coding agent 壳子 可部分替代 Claude Code / Codex CLI OpenClaw 个人 AI 助手 / 控制平面 手机、电脑、聊天入口、系统任务自动化 不替代模型，更多是控制入口 Hermes Agent 长期运行、自我改进的 Agent 框架 记忆、技能沉淀、跨会话任务、长期自动化 不替代 Claude/Codex，更像上层编排 可以简单理解成： ...