AI-Agents

你让悟空对比两个刚发布不久的开源框架，它自信满满地输出了三千字分析，但你一查官网，发现核心特性全是幻觉；你让它分析一份 CSV 销售数据，它用纯文本「心算」了一堆增长率，结果和你用 Excel 拉出来的数字对不上；你让它帮你建一个钉钉待办，它给你写了一段完美的 API 调用建议，但就是没真正执行。

不是 AI 不够聪明，是你只给了它「大脑」，没给它「双手」。

在前面的六篇文章中，我们解决了需求澄清、流程拆解、交付标准、风格对齐、迭代反馈和上下文稳定性。但这些技巧都聚焦在纯文本交互层面。

当任务涉及实时信息、精确计算、外部系统操作时，纯 LLM 推理会遇到物理天花板：知识截止、数学弱项、无执行环境。此时，继续用「聊天」模式硬扛，只会得到看似专业实则不可用的结果。

今天，我们探讨技巧七：如何通过「工具协同」，显式调度 AI 的外部能力，让协作从「对话建议」升级为「端到端执行」。

如果把 Agent 拆解成一个公式，最简单的表达就是：

Agent = Model + Harness

Model 负责思考、推理、决策；Harness 负责循环控制、工具路由、状态管理。过去一年，社区的目光几乎全部聚焦在 Model 上——谁的能力强、谁更便宜、谁上下文更大。但 Anthropic 工程团队最近发布的 Managed Agents 架构文章揭示了一个被忽视的事实：

“Harnesses encode assumptions about what Claude can’t do on its own. Those assumptions go stale as models improve.”

Harness 编码了关于"模型做不到什么"的假设，而这些假设会随着模型能力提升而迅速过时。一个更有趣的推论是：模型越强，Harness 的设计就越重要——因为越强的模型需要越精密的控制结构，才能把能力转化为可靠的产出。

这篇文章从 Anthropic 的工程实践出发，拆解 Agent 架构的核心设计模式，以及"面向未来的 Harness"到底长什么样。

去年底，钉钉内部发生了一件事。一个做智能客服的产品经理发现，他给企业客户做的 AI 解决方案，从需求确认到方案交付平均要 14 天。他拉了一下链路：客户提需求给销售（1 天）→ 销售转给解决方案团队（等 2 天）→ 解决方案写 PRD 转给产品（等 1 天）→ 产品评审排期（等 3 天）→ 技术实现（5 天）→ 交付验收（2 天）。14 天里，真正在"干活"的时间不到 5 天，剩下 9 天全是等待——等人、等审批、等排期、等信息同步。

他跑去找他的主管说：“我们给客户做 AI 提效工具，但我们自己的组织效率，比客户还低。”

这句话刺痛了人。但更刺痛的是——这不是钉钉一家的问题，这是几乎所有想做 AI 转型的公司都会撞上的墙。不是不知道终局应该长什么样，而是不知道第一个可用版本怎么做——像做产品一样，先跑起来，再迭代。

前几天跟一个做 Agent 平台的朋友聊天，他说了一句让我印象很深的话：“我们花了半年调 prompt，好不容易让 Agent 在电商客服场景跑到了 90 分。结果客户说要扩到金融场景，我们一测——40 分都不到。”

我问他打算怎么办。

他苦笑：“重新调呗。再花半年。”

这个对话浓缩了当前 AI Agent 面临的最核心矛盾：我们造出了能力惊人但本质上是"静态"的系统。它在训练过的分布上表现惊艳，换个分布就翻车；它部署的那一刻就被冻结，遇到新场景只能等人类手动干预、重新训练。

这让我开始思考两个看似不同、实则紧密相连的问题：泛化（Generalization） 和 进化（Evolution）。

今天下午我做了一件听起来有点奇怪的事——让 AI 读完了我自己的 174 篇博客，提炼出写作风格，写成了一份可执行的配置文件，然后告诉它：“以后每次写文章就按这个标准来，写完还要自己更新它。”

它真的照做了。不仅生成了一份包含六大风格特征、两种文章模板、四个薄弱环节和改进路线图的 Skill 文档，还自动附加了一条"进化协议"——每次使用完毕后检查是否需要更新。

这不是 prompt engineering，也不是 RAG。这是给 Agent 建程序性记忆（Procedural Memory）。

很多人给 AI 配了知识库、写了几百行 system prompt，但用起来总觉得"不长进"。问题不在于模型，而在于记忆的结构。静态 prompt 是一次性指令，而可进化的 Skill 是活的——它会随着使用自动迭代、越用越准、越用越像你自己。

之前写过一篇用 AI 把 VOC 变成自动化流水线，讲的是整条流水线的架构——采集、分析、路由、执行。反馈不错，但也有读者指出一个关键问题：中间的部分（分类、路由）其实相对好做，真正难的是一头一尾。

“头"是用户问题理解——用户说"页面打不开”，你能不能自动搞清楚是哪个页面、什么场景、能不能复现、根因是什么？

“尾"是自动验证——修完 bug 之后，你能不能自动生成测试用例来证明"确实修好了，而且没有搞坏别的东西”？

这两个环节恰好是 AI Native 流程区别于传统自动化的核心：传统自动化靠规则，处理的是确定性问题；AI Native 靠理解和推理，处理的是模糊性问题。这篇文章就把这一头一尾拆开讲透。

想象你团队来了个新同事——聪明、勤快、知识面广，但对你们的业务一无所知。第一天上午你走过去说：“帮我整理一下那个项目的材料。” 没说哪个项目，没说给谁看，没说什么格式，没说什么时候要。

他大概率会交出一份正确但平庸的文档。你看了一眼：“这也太模板了。”

这不是他能力不行，是你没把活派清楚。

现在把"新同事"换成 AI。同样的场景，同样的结果。但大多数人的反应不是"我没说清楚"，而是"AI 不够聪明"。事实上，AI 落地的真正瓶颈不是模型能力，是任务委托能力——一项被严重低估的管理技能。

上周帮一个客户上线了一个"智能周报助手"。需求方的原话是：“帮我们的销售团队自动生成周报。”

听起来很简单。但往下聊五分钟，你会发现这句话背后藏着至少二十个未定义的决策：周报包含哪些维度？数据从哪来？不同区域的销售负责人关注点一样吗？“好的周报"到底长什么样？客户自己也说不清。

最终的解决方案不是一个固定模板的报表工具，而是一个 Agent——它能根据每个销售负责人的历史偏好、当周数据特征、团队上下文，动态决定周报的结构、重点和措辞。

这件事让我重新思考一个问题：Agent 的核心价值到底是什么？ 不是"自动化”，不是"降本"，而是——它是目前唯一能规模化解决"复杂个性化需求"的技术方案。

上个月参加一个 Agent 产品的内部评审，产品经理拿出一张 benchmark 表格：准确率 92%、响应时间 1.2 秒、幻觉率 3%。数字很漂亮，领导很满意。

然后我问了一个问题：“这个 92% 的准确率，是在什么任务上测的？”

回答是一组通用 QA 数据集。

我又问：“你的目标用户是电商运营，你有没有用电商运营真实工作场景的任务来测？”

会议室安静了五秒钟。

这就是今天 Agent 评测的核心矛盾：我们在用"通用考试"的成绩来预测"专业岗位"的表现。 这就像用高考数学成绩来判断一个人能不能当好外科医生——逻辑上不成立，但大家都在这么干。

如果你在过去二十年里分别做过搜索引擎、广告系统、推荐系统，再到今天做AI Agent，你可能会有一个越来越强烈的感觉：这不就是同一个生意吗？

表面上看，Google做搜索、Meta做广告、抖音做推荐、OpenAI做Agent，四个完全不同的产品形态，四个不同的技术栈，甚至四个不同的行业叙事。但如果你把外壳剥掉，盯着底层看，会发现一个令人不安的事实：这四代系统的核心逻辑，从来没有变过。

它们都在做同一件事——在信息过载的世界里，帮用户匹配到最相关的东西，然后从匹配效率的提升中抽税。