惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
雷峰网
雷峰网
量子位
有赞技术团队
有赞技术团队
阮一峰的网络日志
阮一峰的网络日志
The Cloudflare Blog
博客园 - Franky
罗磊的独立博客
宝玉的分享
宝玉的分享
博客园_首页
腾讯CDC
The GitHub Blog
The GitHub Blog
D
DataBreaches.Net
IT之家
IT之家
D
Docker
Microsoft Security Blog
Microsoft Security Blog
博客园 - 司徒正美
V
V2EX
月光博客
月光博客
N
Netflix TechBlog - Medium
爱范儿
爱范儿
I
InfoQ
P
Proofpoint News Feed

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
AI Agent的提示词框架
瞳仔设计说 · 2025-11-11 · via 人人都是产品经理

提示词,不只是指令,更是认知的接口。在AI Agent时代,提示词框架决定了智能体的边界、角色与行为方式。本文将从结构化思维出发,拆解提示词的构建逻辑,帮助你理解如何通过语言塑造AI的“人格”与“能力”。

AI Agent是一个系统,其中LLM模型在连续、独立的循环中利用一组工具来完成给定任务。根据 Anthropic的专家的定义,Agent的核心组件是其环境(其运行位置)、工具(它可以调用的功能)以及定义其核心目标的简单系统提示。Agent自主工作,根据从其工具接收到的信息更新其决策,直到任务完成。

本文为设计Agent的决策者提供一个清晰的战略框架,以评估何时以及为何部署AI Agent,重点是如何实现价值最大化以及降低风险。

1.0 核心决策框架:何时使用 AI Agent

部署 AI Agent 是一项重要的工程资源投入,并非所有问题的合适解决方案。以下四个标准必须被视为强制性的准入机制,以确保此项投资的合理性。Agent 最适合处理既复杂又有价值的任务;绕过此严格评估将直接导致资源浪费和项目失败。

在承诺采用基于 Agent 的架构之前,团队必须根据此先决条件清单验证其用例。

1.1 任务复杂性分析

任务是否足够复杂,需要 Agent?

如果人类可以轻易规划出一个清晰的、逐步执行的流程来完成该任务,那么就不需要 Agent。在这种情况下,采用更简单、更可预测的基于工作流的方法更为合适且资源效率更高。Agent 的理想用例是最终目标明确,但实现该目标的具体路径不明确或不可预测的任务。这要求模型能够做出决策,根据新信息调整策略,并在模糊的路径中找到解决方案。

1.2 任务价值评估

任务的价值是否足以证明所需资源的投入是合理的?

Agent会比其他解决方法消耗更多的资源——包括计算资源和开发时间。因此,其部署应留给”高杠杆”的任务。高价值任务是指一旦实现自动化,能带来显著回报的任务。例如,直接产生收入的任务,或能为高技能员工节省大量时间,使他们能够专注于更高杠杆率工作的任务。

1.3 工具可行性评估

Agent 是否能够获得必要的工具和信息?

Agent 的有效性完全取决于其所获工具的质量和可用性。当经过前面的价值评估后,确定要使用Agent来解决问题时,一个不容商榷的先决条件是,必须清点并验证所有必要的工具和数据源是否能够全部提供给Agent使用。如果关键工具不可用或无法构建,则必须缩小项目范围,直到满足此条件。

1.4 错误成本与可恢复性分析

错误的成本是多少?检测和纠正错误的难易程度如何?

在决定授予 Agent 多大程度的自主权时,必须将潜在的错误风险作为核心考量。这需要仔细分析两种截然不同的情况:

  • 高成本错误: 对于错误难以检测或纠正成本高昂的任务(例如,在无监督的情况下修改生产代码),完全独立的 Agent 并不适合。这些场景需要采用人为监督的方法,即由人员在关键节点审查并批准 Agent 的行动。
  • 低成本错误: 对于错误易于恢复且成本不高的任务,则更适合让 Agent 独立工作。例如,网络搜索中的错误,可以通过尝试不同的查询或再次检查结果来轻松纠正。

2.0 Agent的实际使用场景示例

下图中表格内容是由 Anthropic 专家提供的几个真实案例。每个用例都展示了上述原则的组合,阐明了为何基于 Agent 的方法是战略上合理的。

理解这些成功的使用场景可以为实践奠定基础。下一节将详细阐述有效构建这些系统的指导原则。

3.0 Agent 的设计原则

构建可靠的 Agent 不仅仅是编写系统提示词;更需要塑造 Agent 的环境并引导其推理。

3.1 像 Agent 一样思考并提供启发式方法

对于开发者而言,最重要的原则是构建关于 Agent 环境与约束的心智模型。正如我们内部构建这些系统的专家经常说的:”如果人类都无法理解你设计的 Agent 应该做什么,AI 也将无法理解。”

这需要进行”概念工程”——为 Agent 提供合理的启发式方法来指导其行为,而不仅仅是僵化的文本指令。对此最有效的思维模式是将其视为管理一个”刚大学毕业的新实习生”。你必须明确说明他们应遵循的一般原则,以应对模糊性。有效的启发式方法示例包括:

  • 不可逆性: 指示 Agent 避免可能导致不可逆损害的操作。这一原则对于开发 Claude Code 以保护用户环境免受意外损害至关重要。
  • 停止条件: 明确告诉模型何时找到了足够好的答案,以免它不必要地持续搜索不存在的“完美”来源。
  • 资源预算: 为 Agent 提供工具使用量的量化指导。例如,指示它对于简单查询应使用少于 5 次工具调用,而对于更复杂的查询,最多可使用 10 到 15 次。

3.2 战略性的工具设计与选择

工具的选择和设计至关重要。必须向 Agent 提供关于在公司上下文中为特定任务使用哪些工具的明确原则(例如,指示 Agent 默认搜索 Slack 以获取内部公司信息)。一个”好的工具”具有以下几个关键特征:

  • 一个简单、准确的名称,能清晰反映其功能。
  • 一个格式良好、描述清晰的说明,人类工程师能够轻松理解和使用。
  • 功能区分明确,以避免混淆模型。例如,六个非常相似的搜索工具应合并为一个更强大的单一工具。

3.3 管理运营现实

Agent 比简单的工作流程更不可预测,可以理解为一个黑箱,微小提示词的更改可能会产生巨大的意外副作用。例如,让agent”找到尽可能高质量的来源”可能会导致 Agent 无限循环搜索,以至于大大浪费token。即使现在的claude已经可以提供20万token的上下文窗口,但能够很好的管理20 万token的上下文窗口仍然是处理长期运行任务的关键挑战。下面的策略有助于更好的利用上下文窗口特点并扩展 Agent 的有效记忆:

  1. 压缩: 使用一个专用工具,当 Agent 接近其上下文限制时(通常在19万token左右)自动调用。该工具总结对话内容,并将一个密集的摘要传递给模型的新实例,使其能够在完整上下文的情况下继续任务。
  2. 外部记忆: 允许模型将其“记忆”或中间思考写入外部文件。然后 Agent 可以根据需要参考该文件,从而有效地无限扩展其上下文窗口。
  3. 子 Agent: 将特定的、上下文繁重的任务委托给专门的子 Agent。这些子 Agent 执行其任务,然后将压缩后的摘要结果返回给主导 Agent。此策略用于我们的高级研究功能,以管理复杂的多源查询,同时节省主导 Agent 的上下文窗口。

然而,这些实施原则只有在能够严格衡量其影响时才有效,这就引出了评估这一关键环节。

4.0 一种实用的评估方法

评估 Agent 性能比评估简单系统更复杂,但对于取得有意义的进展至关重要。没有系统性的评估,提示词工程就会变成代价高昂的猜测,而非工程。本节概述了一种务实的、迭代式的 Agent 性能衡量方法。

4.1 有效评估的核心原则

  • 从小处着手: 不要一开始就构建一个庞大的、全自动的评估套件。一套小而一致的优质测试用例,即使最初是手动运行的,也能很好地指示更改是否在改进系统。
  • 使用真实任务: 在反映其真实世界应用的任务上评估 Agent,而非任意或合成的问题。例如,编码 Agent 应在真实的工程问题上进行测试,而不仅仅是竞技编程挑战。
  • 利用 LLM 作为评判者: 对于输出结构多样或不可预测的情况(如研究报告),使用另一个带有清晰、明确评分标准的大语言模型来评判 Agent 输出的质量和准确性。这比简单的字符串匹配更稳健。
  • 优先进行人工评估: 最终,没有什么能完美替代人工手动测试系统。审查运行记录和观察 Agent 的行为对于深入了解其优势和劣势至关重要。

4.2 关键评估方法

下表总结了评估 Agent 性能的具体、实用方法。

持续应用这些评估方法是推动 Agent 性能迭代改进的关键。

5.0 结论与建议

成功部署 AI Agent 需要战略性、有纪律的方法。构建 Agent 的决策应基于对任务复杂性、价值、工具可行性和错误成本的四部分评估框架。一旦确定 Agent 是合适的解决方案,成功则取决于周密的实施,这需要清晰的启发式方法、精心设计的工具和稳健的评估来指导。

最终建议是采用所有产品与工程负责人熟悉的方法论:为您的 Agent 构建一个最小可行产品,并通过迭代开发周期进行改进。从一个简单的提示词和一套基础工具开始。观察系统在何处失败或行为异常,并将这些观察结果视为用户反馈。这些失败模式应为 Agent 下一迭代版本的”产品待办列表”提供信息,指导您对其提示词、工具和启发式方法进行改进。这种务实的方法——从简单开始,用真实任务进行测试,并根据观察到的行为系统地改进——是构建稳健且有价值的 AI Agent 的最有效途径。

本文由 @瞳仔设计说 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议