27 posts tagged with "AI Agent 开发"

OpenSpec 解决了一个我在 AI 编码里反复踩的坑：你和 AI 达成的共识，/clear 之后全没了。

• 问题本质：AI 在长对话中遗忘早期约束，清空上下文后设计共识归零
• OpenSpec 的解法：把共识写成结构化文档（proposal → spec → tasks），存进文件系统，不依赖对话记忆
• 核心流程：Propose → Apply → Archive，四步闭环，所有变更可追溯
• Delta Spec 机制：改需求不重写规格，用 ADDED/MODIFIED/REMOVED 增量描述，自动合并
• 和 Superpowers 的关系：OpenSpec 管"写什么"，Superpowers 管"怎么写"——一个定方向，一个定纪律
• 得物团队落地数据：10 天净增 25,546 行代码，研发提效 36%，关键是把规范写成 AI 的"可执行契约"

agent-browser 把浏览器从"给人用的 GUI"变成了"给 AI 用的 API"。

1. 定位：专为 AI Agent 设计的浏览器操控工具，自然语言输入、结构化结果输出。
2. 两种实现：Vercel agent-browser 是 Rust CLI（二进制 7MB），browser-use 是 Python 框架。
3. 核心差异：传统自动化写死每一步，agent-browser 是目标驱动——只关心"做到没有"。
4. 底层原理：CDP 直连 + Accessibility Tree 快照，context 用量比完整 DOM 少 90%。
5. 实际数据：WebVoyager 成功率 91.3%，单任务成本不到 $0.09。
6. 2026 趋势：MCP 集成、本地优先、反 Bot 对抗升级三条主线。

软件开发范式的底层逻辑变了——从瀑布到敏捷再到 AI 开发，不是在改进旧流程，而是把整个开发流程替换掉了。

• 瀑布模型：靠前期规划，像从零攒一辆摩托，上线那天才知道对不对
• 敏捷开发：靠快速反馈，从滑板迭代到摩托，但每一步仍然要人写代码
• AI 开发：靠意图表达，你描述要什么，直接给你成品摩托
• 核心转变在于驱动力的迁移：Plan → Feedback → Intent
• 效率提升不是"AI 写代码更快"，而是消灭了中间的等待和沟通成本

别再把 AI 当成"更快的程序员"——它在替换开发流程本身，不只是加速写代码这个动作。

Skill、MCP、Plugin、Marketplace 四个扩展体系完全可以兼容，不需要重构现有生态。

1. 层级定义：MCP 是底层通信协议，Skill 是 Agent 任务封装，Plugin 是 IDE 原生扩展，Marketplace 是分发层。
2. 兼容核心：三层映射规则——MCP 工具 → Skill 动作 → Plugin 功能，统一全局 ID 标识。
3. 落地方案：Codex 内置 MCP 桥接层，可直接调用 Claude 生态的所有 Skill 无需额外开发。
4. 价值收益：一次开发多端分发，开发者无需为不同平台重复实现相同功能。

Agent 死循环不是极端情况，是给模型自由度必须付的代价。

• 直接原因：工具调用失败后盲重试——不换参数，反复撞同一堵墙。
• 深层原因：循环缺少收敛信号，Thought 和 Action 之间没有"该停了"的显式判断。

1. 第一层防御：max_steps 硬限制，两行代码兜住 80% 的翻车。
2. 第二层防御：把 Finish 做成一个 Action，循环有了天然终止条件。
3. 第三层防御：system prompt 里写死"重试失败就换策略"，主动避障。

• 工程底线：step_id + 全局超时 + 连续重复 Action 检测，别信 Agent 能自己收敛。
• 三层防御一起上，单靠任何一层都有盲区。

ReAct 是默认范式但不是唯一解——选错工作模式比选错模型更致命。

1. Function Calling：无推理链的直接工具调用，延迟最低，仅适合单步任务。
2. Plan-and-Execute：先规划全局再逐步执行，长任务完成率高 2-3 倍，但无法动态调整。
3. Reflection：生成 → 批评 → 修正循环，能自纠低级错误，代价是每轮多烧一倍 token。
4. Multi-Agent：多 Agent 分工或辩论，适合复杂任务，协调开销和成本是硬伤。
5. Routing：先分类再分发到专精模型，成本可控但分类错误会连锁翻车。

最佳实践：确定性任务→Plan-Execute，开放探索→ReAct，质量敏感→加 Reflection，规模大→Multi-Agent。

ReAct 不是"推理"和"行动"的简单拼接，是把两者编织成一条交替推进的链路：每一步推理都有观测反馈，每一步行动都有推理支撑。

• 定义：模型交替生成"思考"和"行动"，每次行动后把环境返回的观测结果注入下一步推理，形成闭环。
• 与 CoT 的核心差异：CoT 在推理链中"脑补"事实，ReAct 通过外部工具或环境把推理接地——幻觉会触发不符预期的观测，反过来暴露推理错误。
• 关键循环：Thought → Action → Observation → Thought，这个循环给 Agent 带来自我纠错能力——工具调错了？看返回就知道，下一步改。
• Action Space 设计：工具描述、参数 schema、返回格式，这三样写不好，ReAct 的效果直接打对折。
• 常见翻车：Agent 陷入重复 Action-Observation 死循环，没有收敛判断——需要加 max_steps 或让模型自己输出 Finish。
• 适用场景：需要多步信息检索、代码执行、API 调用的任务。简单的单轮问答用 ReAct 是过度设计。

OpenClaw 自己没有"防锁屏"功能——让远程电脑一直在线不被系统休眠干掉，靠的是 操作系统层面 的电源管理配置。

• 根本问题：macOS/Windows/Linux 默认都会在空闲时进入休眠，系统的电源管理策略会直接挂起进程，Gateway 连接中断，远程控制失效。

1. macOS 解法：sudo pmset -a sleep 0 全局禁休 + caffeinate -s 进程级防睡 + LaunchDaemon 系统级自启，三层叠加 才能保证锁屏后服务不掉。
2. Windows 解法：电源计划设"从不睡眠"只是第一步，还要关混合睡眠、禁用 USB 选择性暂停、组策略禁用待机状态 S1-S3，否则 硬件省电策略会偷偷断网。
3. Linux 解法：systemctl mask sleep.target suspend.target 从 systemd 层面禁掉休眠路径，配合 logind.conf 忽略合盖/电源键事件，GNOME 只关屏不睡眠。

• 关键区分：LaunchDaemon（系统级，开机即跑）≠ LaunchAgent（用户级，登出即停），远程无人值守必须用前者。
• 验证标准：锁屏 30 分钟后 Gateway 日志仍有新消息进来，pmset -g | grep sleep 全显示 0，才算配置成功。

ClaudeCode 客户端消息流的有序性，本质上是 单写者 + 显式序号 + 受控并发 换来的工程纪律，不是靠运行时去猜消息该怎么排。

要点拆解：

1. 所有 stream 事件先汇入统一写入通道，由 序号 决定渲染顺序，不按到达时间。
2. 工具并发被框死在 读可并行、写必串行 的边界内。
3. UI 层只信任已经定序的快照，从不直接消费裸 SSE，否则就是乱序事故的源头。
4. 回合作为原子单位，失败整体丢弃，不修补半截回合。

理解这套规则，比追着 SDK 文档更有用。

OpenCode 客户端保证消息有序，靠的不是排序算法，而是 "按 partID 分桶 + 桶内就地更新" 的状态合并模型。

核心设计 三 点：

1. 每个 part 由服务端分配全局唯一 id，创建顺序 = 渲染顺序
2. 后续 part.updated 事件按 id 就地覆盖，不动 partOrder
3. 断线重连先拉快照、再续 SSE，幂等更新天然无缝衔接

反面教材：早期每次更新都 setMessages([...messages]) 全量复制，消息一长 CPU 直接飙满。Streaming UI 的性能瓶颈从来不在网络，而在前端的更新粒度。