企业官网建设流程全解析

Agent项目失败，是因为你不想让它"不够聪明"

反直觉论点：Agent项目失败的原因不是技术不够强，而是团队不愿意在"让它不够聪明"上做设计。越聪明的Agent越不可靠，越窄的Agent越值钱。

一、一个观察

你有没有注意到，成功的AI Agent产品和失败的AI Agent产品，有一个关键差异：

成功的产品，Agent能做的事很少。失败的产品，Agent什么都能做。

这不是随口感慨。我们来看数据：

• Sierra做AI客服，2023年成立，2026年E轮融资9.5亿美元，估值158亿美元。它只做一件事：帮客户解决问题，解决不了就转人工。它不会闲聊，不会推荐商品，不会主动发邮件。
• Apple Intelligence的设计哲学是"窄而深"：Siri理解设备端意图，复杂问题交给ChatGPT。它不试图做一个无所不能的助手。
• Anthropic官方Agent构建指南的第一条原则：“优先选择最简单的方案，仅在必要时增加复杂性。”（原文：When building with LLMs, the most successful solutions are often the simplest.）

再看失败的那边：Gartner 2024年的研究指出，30%的生成式AI项目将在概念验证后被放弃，仅28%能完全达到预期ROI。失败最常见的原因是"对AI能力抱有不切实际的期望"。

"不切实际的期望"翻译一下就是：你期望Agent什么都能做。它不能。

为什么？

二、"让它更聪明"是一个陷阱

2.1 智能不等于可靠

一个能做100件事的Agent，和一个只能做5件事但每件都做对的Agent，哪个更有用？

答案取决于谁在用，以及出错成本有多大。

如果是一个开发者自己在终端里用Claude Code，能做100件事是好事。用错了自己修，成本自己担。Claude Code的用户是专业开发者，他们有能力判断Agent的输出是否正确，也有能力在出错时快速修复。

但如果是一个非技术用户——一个客服、一个销售、一个运营人员——他们不需要Agent"能做很多事"，他们需要Agent"做的事一定对"。

智能和可靠是两个维度，而且经常互相矛盾。

这不是直觉，是数学。

Agent越"聪明"（自主性越高、决策空间越大），它的行为就越不可预测。不可预测不等于不智能，但不可预测等于不可信赖。

用一个更形式化的表述：

可靠度 = 准确率 ^ 决策维度数

一个Agent在每种场景下都有95%的准确率。看起来很高。但如果你让这个Agent同时负责5个场景，用户对它的整体信任度不是95%，而是：

95% × 95% × 95% × 95% × 95% = 77.4%

10个场景呢？95%^10 = 59.9%。近一半的概率会出问题。

能力维度每增加一个，整体可靠度就指数级下降。这就是为什么成功的Agent产品都是"窄"的：不是因为他们做不到"宽"，而是因为"宽"会稀释信任。

Sierra只做客服解决。Apple Intelligence只做设备端意图。不是能力限制，是设计选择。

2.2 "聪明"的Agent有一个隐蔽的失败模式

一个"聪明"的Agent最危险的地方不是它做错了，而是它做错得看起来很对。

一个"笨"的Agent做错了，你会立刻发现——因为它要么报错，要么给出明显不合理的结果。

一个"聪明"的Agent做错了，它可能给出一个看起来合理、逻辑自洽、语言流畅的答案，但事实上它是错的。而且你无法通过表面判断它错了，因为它的"错误"不在语法层面，在语义层面。

这种失败模式在生产环境中极其危险：它延迟了错误的发现时间。

一个客服Agent给了用户一个错误的退款政策，用户当时不会发现。三天后用户发现退款没到账，打电话投诉，这时候你才知道Agent给了错误信息。修复成本已经从"改一个输出"变成了"处理一单客诉"。

2.3 现实中的教训

一个在家庭服务器跑了三个月AI Agent的开发者写了这样的总结：

“指令模糊是灾难的开始。'帮我检查邮件’变成了Agent自作主张回复垃圾邮件。'监控社交媒体’变成了到处点赞。你以为的常识，AI根本没有。现在我学乖了：扫描这几个人的邮件，标记紧急的，未经许可不准回复。就是要这么死板。”

这段话的关键不在于Agent做了蠢事——这在预期之内。关键在于解决方案：不是让Agent"更聪明地理解指令"，而是缩小指令的范围，消除歧义，加上硬约束。

解决问题的方式不是提升智能，是降低自由度。

三、为什么团队不愿意"让它不够聪明"

3.1 交付压力：功能列表比可靠性好看

产品经理需要一个能演示的功能列表。投资人在看deck时想看到"这个Agent能做多少事"。

“我们的Agent能自动完成客户服务、营销邮件、数据分析、会议纪要、社交媒体管理”——这比"我们的Agent能解决客户退款问题"听起来有吸引力得多。

但在演示环境和生产环境之间，隔着一个巨大的鸿沟：演示只需要一次成功，生产需要每次成功。

演示的时候，Agent做得很好。因为演示场景是精心挑选的，输入是预定义的，边界case是不存在的。

但生产环境不是演示环境。用户会问Agent没见过的东西。输入会有噪声。边界case会出现。而且每次出现，用户都会记住。

5次成功 + 1次失败 ≠ 5/6的好评。它 = 1次差评。

3.2 "通用"的政治正确

在AI行业，“通用智能”（AGI）是终极叙事。做一个"专用"的Agent，好像在说"我们做不到通用"。这在融资、招人、品牌上都是劣势。

但你看真正赚钱的AI公司：

• OpenAI靠GPT赚钱，但GPT只是一个"通用语言模型"，不是一个"通用Agent"。OpenAI自己的Agent产品是Operator，做的是最窄的事：帮你操作浏览器完成特定任务。
• Anthropic做Claude，但官方Agent指南的核心建议是"用Workflow而不是Agent"——Anthropic自己在告诉你：不要用我的模型做Agent，除非你真的需要。
• Sierra做AI客服，估值158亿美元，做的就是最"窄"的事。创始人Bret Taylor（前Salesforce联席CEO、OpenAI董事会主席）选择做最窄的赛道，不是因为没有野心，是因为他知道窄=可靠=值钱。

越赚钱的Agent产品，越"窄"。这是一个经验规律，不是一个巧合。

3.3 工程师的本能：复杂就是高级

工程师喜欢解决难题。"让Agent自己决定怎么做"比"给Agent写一个固定流程"更有技术挑战性，更有成就感。

Anthropic的指南把方案分成了三个层次：

1. Workflow（预定义流程）：步骤固定，LLM只负责每个步骤内的决策
2. Agent（自主决策）：步骤不固定，LLM自己决定下一步做什么
3. 多Agent协作：多个Agent分别负责不同任务，自主协调

很多团队上来就选3。但Anthropic的明确建议是：

“从最简单的方案开始，只在简单方案不足时才增加复杂性。”

这跟软件工程的基本原则一致：不要过度设计。但在AI Agent领域，这个原则被"智能"这个词模糊了。很多人认为"用Agent"是更高级的技术选择，就像"用微服务"比"用单体"更高级一样。

但"用Agent"不是更高级，是更危险。就像"用微服务"不是更高级，是更复杂。更复杂只在确实需要时才是更高级。

3.4 Thin Harness, Fat Skills：一个正在形成的设计范式

2025-2026年间，一个叫"Thin Harness, Fat Skills"（轻驾驭、重技能）的Agent架构设计范式正在社区中形成共识。核心理念：

将大模型当做纯粹的推理引擎，不处理零散复杂的临时指令。

这个范式的主张是：Harness（驾驭层）应该尽量薄，只做三件事：理解用户意图、选择合适的Skill、把结果返回给用户。所有的复杂逻辑都应该放在Skill（技能）里，每个Skill做一件事、做到可靠。

这跟"让它不够聪明"是同一个思路：Harness不聪明，但Skill专业。不聪明的驾驭层+专业的技能层 > 聪明的驾驭层 + 粗糙的技能层。

ECC项目（182K+ stars）就是一个这种范式的实践。它不试图让Agent"什么都会"，而是把每个能力做成独立的Skill，Harness只负责调度。

四、"不够聪明"的设计长什么样

4.1 死板但有保障

一个运营团队的日报Agent，正确的设计不是"AI理解你的需求，自主完成日报"，而是：

# 这是一个Workflow，不是一个Agent# 步骤完全确定，不需要LLM做任何决策defdaily_report_workflow():# 1. 每天固定8:00触发（cron）# 2. 从固定数据源拉取固定指标metrics={"dau":fetch_dau(),"revenue":fetch_revenue(),"conversion_rate":fetch_conversion_rate(),}# 3. 用固定模板生成日报report=REPORT_TEMPLATE.format(**metrics)# 4. 发送到固定渠道send_to_slack(channel="#daily-report",content=report)

这个"Agent"“不聪明”。它不能理解"我觉得今天的日报应该重点关注XX"。它不能自己决定换一个数据源。它不能在数据异常时自动写一段分析。

但它每次都能按时、准确、稳定地出日报。它不会有一天突然"忘记"拉取DAU。它不会有一天把日报发到错误的Slack频道。它不会有一天生成一段关于数据异常的"分析"——而那段分析恰好是错的。

4.2 边界清晰：定义"不能做什么"比"能做什么"更重要

"不够聪明"的设计核心是：明确定义Agent不能做什么，而不是它能做什么。

一个有边界的设计：

# Agent能力边界定义capabilities:can_do:-query_order_status# 查询订单状态-process_refund:# 处理退款constraints:amount_max:500# 金额上限500元within_days:30# 30天内require_approval:false# 不需要人工审批must_escalate:-refund_amount_over_500# 超过500元转人工-refund_after_30_days# 超过30天转人工-any_complaint# 任何投诉转人工-user_requests_human# 用户要求人工cannot_do:-modify_order# 不能修改订单-issue_discount# 不能发放折扣-access_other_user_data# 不能访问其他用户数据

一个没有边界的设计：

# 反面示例：能力模糊capabilities:can_do:-"处理客户的各种问题"# 什么叫"各种"？-"根据上下文自主判断"# 判断的边界在哪？

哪个更安全？哪个更容易被用户信任？哪个在出问题时更容易排查？答案显而易见。

4.3 失败模式可控：知道它会怎么失败

"不够聪明"的Agent有一个关键特性：它的失败模式是可预测的。

• 它要么成功完成范围内的事
• 要么明确告诉你"这个我处理不了，帮你转人工"

而"聪明"的Agent的失败模式是不可预测的：它可能给出了一个看起来合理但错误的答案，你可能到很晚才发现。

这在工程上有一个重要推论：可预测的失败可以被设计防护，不可预测的失败只能靠运气。

如果一个Agent在遇到超出范围的问题时一定会转人工，你可以设计一个监控指标：escalation_rate（转人工率）。如果这个率突然升高，说明Agent的覆盖范围需要扩展。这是一个可控的改进循环。

如果一个Agent在遇到超出范围的问题时"自主发挥"，你无法监控它的错误率——因为你不知道它的输出是不是错的，直到用户投诉。

可控的失败 > 不可控的"成功"。

五、什么时候"聪明"是必要的

不要误解：不是所有场景都应该"不够聪明"。

需要Agent自主决策的场景确实存在：

• 开放式探索（分析一个从未见过的数据集，步骤无法预定义）
• 创意性任务（根据设计文档写新功能，每一步的输出影响下一步）
• 无法穷举步骤的复杂任务（修复一个未知原因的Bug，需要不断试错）

但注意这些场景的共同特征：步骤无法预先定义，每一步的输出影响下一步的决策。

如果你的任务步骤是可以预先定义的，用Workflow。用Agent不是"更先进"，是"更危险"。

Anthropic的指南给出了明确的选择框架：

一个常见的错误是把"偶尔需要灵活性"等同于"需要Agent"。

大多数业务任务95%的时候步骤是确定的，5%的时候需要灵活处理。正确的做法是：用Workflow覆盖95%，在Workflow中嵌入一个"异常处理"节点——当遇到5%的特殊情况时，转人工或者触发一个受约束的子流程。

而不是为了5%的灵活性，把整个系统设计成Agent。

六、一个推论：窄不是弱，窄是专业

如果我们接受"Agent项目失败是因为不够窄"，那么下一个问题是：怎么才能做到"窄"而不显得"弱"？

答案是：窄不是弱，窄是专业。

Sierra只做客服，158亿美元估值。不是因为它"弱"，是因为它在这个领域做得比任何"通用Agent"都好。

一个只做"日报生成"的Agent，如果每次都准时、准确、格式统一，它比一个"能做日报但有时会出错"的通用Agent有用一百倍。

专业的反面不是通用，是可靠。

更深层地看，"窄"是一种设计决策，不是能力限制。做一个窄的Agent，需要你深入理解一个领域，把它的所有情况穷举出来，为每种情况设计确定性的处理逻辑。这比做一个"什么都交给AI自己决定"的Agent难得多。

因为"窄"意味着你必须做领域建模。你必须知道这个领域的边界在哪。你必须知道哪些情况是"正常"的、哪些是"异常"的。你必须为异常情况设计兜底方案。

做窄的Agent，需要更多的领域知识，不是更少。

而"让它什么都做"，表面上是给Agent更多自由，实际上是你自己没有想清楚。你不知道这个领域的边界在哪，所以你让AI自己去探索。这不是"智能"，这是"偷懒"。

Gartner的数据已经说了：30%的AI项目在PoC后被放弃，20%彻底失败。最常见的原因是"对AI能力抱有不切实际的期望"。

不切实际的期望，往往来自于你自己没有做足够的设计。

所以下次你在设计一个Agent时，先问自己三个问题：

1. 这个任务有明确的步骤吗？如果有，用Workflow，不要用Agent。
2. 如果它做错了，我能预测它怎么错吗？如果不能，缩小它的范围，直到你能预测。
3. 如果它遇到处理不了的事，它会怎么告诉我？如果答案不是"明确转人工"，重新设计它的边界。

让Agent"不够聪明"，是你能为它做的最聪明的事。

数据来源：

• Sierra：2026年5月E轮融资9.5亿美元，估值158亿美元（Tiger Global和GV领投）；2025年11月ARR破1亿美元
• Anthropic官方Agent构建指南（2025）：Workflow vs Agent选择框架，“优先最简方案”
• Apple Intelligence设计哲学：本地意图识别+ChatGPT处理复杂查询
• Gartner 2024：30%生成式AI项目PoC后被放弃；仅28%达到预期ROI；20%彻底失败
• 24/7运行AI Agent三个月的踩坑总结（开发者博客）
• Google DORA 2024报告：AI辅助开发稳定性下降7.2%
• Google DORA 2026年1月续作：AI辅助软件开发的ROI框架
• Thin Harness, Fat Skills架构范式（2025-2026社区共识）
• ECC项目（182K+ stars）：Harness性能优化系统实践