# AI Agent

这篇文章围绕 AI Agent 的 Harness Engineering 展开，核心观点是：大模型已经足够强，可以参与研发交付，但如果没有一套足够扎实的 Harness（约束与治理体系），它仍然只是高级玩具；只有把它纳入工程控制面，它才能成为真正参与交付的协作者。

文章先解释了 Harness 到底在管什么。作者把传统软件工程和 Harness Engineering 做了区分：传统软件工程主要处理确定性问题，而 Harness Engineering 处理的是大模型这种非确定性系统。大模型会受上下文、工具调用、幻觉和状态漂移影响，因此不能只靠 Prompt 约束，而要依赖外部的状态、沙盒、验证器、日志和审批节点。

接着文章用两个坐标轴来定义架构边界：一条轴是执行流路由，是静态预设还是动态自主；另一条轴是状态与上下文，是隐式内置还是显式外部。作者把这四种组合分别对应到无状态链、提示词驱动、传统管道和 Harness Engineering，认为真正适合企业环境的，是把模型意图和外部控制面结合起来的那一类。

文章还专门讲了“伪 Harness”和“劣质 Harness”的问题。前者看似在控制模型，实际上只是把大量约束塞进 Prompt 里；后者虽然有控制流，但可能是暴力重试、重型文档流或者机械的流程堆砌。真正有效的 Harness 应该具备前置验证、最小真相源、物理门禁和可回退的反馈闭环。

在企业场景下，文章强调 Harness 比 Prompt 更重要，因为企业工程环境链路更长、边界更严、试错成本更高。Agent 要面对的不是“能不能写出代码”，而是能否调到正确接口、能否读日志定位问题、能否被人类接手恢复。于是程序员的核心价值也在迁移：从亲手写代码，变成定义目标、卡住边界、掌控节奏、验收结果。

文章用 Aegis 项目举了一个真实实践案例，说明一个 AI Agent 是如何被 Harness 出来的：先收敛目标，不急着编码；再通过 Spec 和 Handoff 对抗上下文腐烂；把 Prompt 溶解进能力路由；把测试和回归前置化；通过日志、状态文档和外部验证，让 Agent 在可控轨道上持续交付。文章认为，真正重要的不是某段神奇 Prompt，而是整套工程控制面。

最后，文章给出了一套落地建议：先搭真相源，再约束执行边界；构建最小能力目录；前置验证闭环；完善恢复机制；逐步释放自由度。整体结论是，AI Agent 时代，最强的程序员不是写代码最快的人，而是最能定义目标、约束非确定性、抓住关键结构并把结果交付出来的人。

这篇文章更像是一篇面向工程实践者的架构方法论总结，重点不在某个具体工具，而在如何把“聪明但不稳定”的模型变成可控、可验证、可交接的生产力系统。

这篇文章是作者对 Codex 新发布的 Computer Use 功能做的实测反馈。作者原本对这类能力抱有期待，认为既然出自 ChatGPT 团队，表现应该会比较强，但实际体验下来并不理想。文章先测试了让它通过视觉方式操控原生微信，结果它一开始连公众号入口都找不到，还尝试过用各种旁路方法去寻找文章链接，但都没有成功。

作者指出，这种 Computer Use 更像是基于纯视觉的操作，速度慢，而且在复杂桌面应用里很容易找错目标。比如本来应该点击窗口右上角的菜单，它却误点到了文章内部图片上的相似按钮，说明它对界面层级和语义理解还不够稳定。文章还提到，微信本身的加密和页面结构，也让它无法像预期那样直接通过数据库或网页搜索拿到内容。

随后作者又测试了让它自动操作网页，去回复一条推文，但结果同样不够好。它虽然能慢慢找到输入框位置，却在粘贴和触发输入事件上反复失败，最后连回复按钮都无法正常激活。作者因此认为，纯视觉式自动化在当前阶段仍然比较鸡肋，尤其在网页场景里，若能直接基于 DOM 操作，效率和成功率会高得多。

文章最后还提到一次普通任务就消耗了大量 token，体验并不划算。整体结论很直接：Codex 的 Computer Use 不是完全不能用，但在原生桌面和网页自动化里都还有明显短板，离“真正好用”还有距离。

这篇文章介绍了作者用 Rust 从零实现一个可自我进化的 AI Agent——Rust-daerwen。作者的核心观点是，真正有生命力的 Agent 不能只会对话，而要把技能、记忆和自我认知都落到磁盘上，做到可版本化、可回滚、可审计。文章把系统拆成了几个层次：记忆、技能、自我模型，以及任务循环、反思循环和主动循环等多个闭环。

作者强调，Agent 的关键不是“壳”有多漂亮，而是能否把一次对话中学到的东西沉淀下来，并在下一次任务里继续使用。为此，他设计了类似 L0/L1/L2 的记忆分层、AAAK 紧凑事实格式，以及通过反思自动生成 wiki、候选技能和改进建议的机制。文章还提到，所有这些内容都能被版本控制和自动提交，保证演化过程可追踪。

另一个重点是“闭环”。作者指出，仅仅生成技能候选并不算进化，必须让 Agent 真的调用自己学到的技能、根据失败记录去修改旧技能、并把新学到的事实写回自我认知。文章举了 skill 反哺、失败驱动进化、AAAK 反哺等例子，说明系统不是静态工具箱，而是会持续学习的结构。

文章后半部分介绍了 MCP 的作用：通过接入 Playwright 等外部工具，Agent 可以自己修复浏览器缺失、自己安装依赖，然后继续完成任务。作者还展示了它如何通过社区 skill hub 自主发现、安装并使用外部技能，让 Agent 具备“借轮子再进化”的能力。

整体来看，这是一篇偏工程实践和架构总结的长文，重点不在于某个单点功能，而在于如何把一个 AI Agent 做成可持续成长的系统。作者试图说明：如果想让 Agent 真正“越用越聪明”，就必须接受它是一个会积累、会反思、会修正自己的长期系统，而不是一次性聊天壳。