AI Agent如何懂你：四层能力拆解

过去两年，AI Agent 圈子里冒出来一堆词：Prompt、Context、Harness、Loop、RAG、Memory、Eval、Tool Calling......

听着挺唬人，背后的问题其实很朴素，你不是只想让 AI "说得好听"。

你想要的是：它理解你的目标，知道你的背景，能查真实世界的信息，能调用工具，能检查结果，错了还能自己改。

一、这几个词到底什么关系？

不是并列，是包含。

Prompt 在最里面。Context 包在 Prompt 外面。Harness 是再外面一层的运行系统。Loop 是 Harness 里让 Agent 真正动起来的循环机制。

复制代码

Harness / Prompt Harness└── Loop：感知 → 决策 → 行动 → 检查 → 再决策 └── Context：这次任务需要带进去的全部信息 └── Prompt：你怎么指挥模型完成任务

换个说法：

Prompt 解决"我该怎么跟模型说"。Context 解决"模型回答前，应该知道什么"。Harness 解决"怎么让它真的去查、去算、去执行、去验证"。Loop 解决"做完一步之后，怎么根据真实结果继续下一步，而不是一口气瞎猜到底"。

下面用一个目标贯穿全文：

日本 5 天，和女朋友一起，预算 2 万人民币，不要特种兵，要浪漫、松弛、好吃、好拍照。

第一层：Prompt Engineering

把"我想要什么"说清楚

Prompt Engineering 是最早被大家熟知的方式。核心很简单：通过更好的提示词，让模型给出更好的答案。

听着像在"写咒语"，本质不是。Prompt 的价值不在堆砌复杂词，而在把任务、角色、约束、偏好、输出格式说清楚。

第 0 步：什么都不说的基线

你说：

帮我规划一个日本 5 天旅行。

模型大概率给你一份普通行程：东京、浅草、涩谷、新宿、京都、清水寺、大阪道顿堀。

能用，但更像旅游网站的通用模板。它不知道你和谁去，不知道你们想不想拍照，不知道你女朋友喜不喜欢逛小店，不知道你们能不能早起，不知道你们要浪漫还是要省钱。

所以它只能给一个"平均正确"的答案。能回答，但不贴身。

第 1 步：给模型一个角色和任务

改一下：

你是一位资深定制旅行规划师，尤其擅长情侣旅行。请为我和女朋友规划一份日本 5 天旅行方案。

这一步会明显变好。模型开始知道：这不是家庭游，不是商务差旅，不是穷游攻略，是情侣旅行。

它会主动考虑两个人的节奏、适合散步拍照吃饭的场景、不要每天都排满、晚上安排有氛围的地方、偶尔留点惊喜和自由时间。

但它仍然在猜。它不知道预算，不知道你们是不是第一次一起出国，不知道女朋友喜欢热闹还是安静，不知道她能不能吃生食，不知道你们有没有非去不可的城市。

它变得"像样"，但还不够"像你们"。

第 2 步：加上约束条件

把已知条件写进去：

你是一位资深定制旅行规划师，尤其擅长情侣旅行。请为我和女朋友规划一份日本 5 天旅行方案，满足以下条件：

同行：我和女朋友，两个人

目标：轻松、浪漫、有记忆点，不要特种兵

预算：总计 2 万人民币左右，含住宿，不含国际机票

节奏：每天最多 2 到 3 个主要地点，保留下午茶或自由散步

偏好：适合拍照、吃得好、不要全是网红排队店

住宿：优先交通方便、晚上安全、附近有餐厅和便利店

饮食：不要每天都吃很贵的餐厅，安排 1 到 2 顿有仪式感的晚餐

输出：给出每天上午、下午、晚上的安排，说明为什么这样排

质变发生在这里。模型不再面对模糊问题，而是在明确边界里做规划。它会控制每天安排的数量，不塞满十个景点；会主动安排散步、咖啡、晚餐；会平衡预算和体验；会避免"早上 7 点出门，晚上 11 点回酒店"。

这是 Prompt 最基本的能力：把"通用答案"收窄成"符合你约束的答案"。

但还有问题------你说"浪漫"，模型未必知道你说的浪漫是什么。你说"松弛"，模型未必知道松弛到什么程度。你说"适合拍照"，它可能理解成热门打卡点，而你要的可能是安静街区、小众咖啡馆、黄昏河边散步。

第 3 步：给 Few-shot 示例，让模型知道"好答案长什么样"

光说要求不够，给一个你认可的示例：

请参考下面这种安排风格：

示例：某一天的安排

上午 10:00｜酒店附近慢慢吃早餐，不赶早高峰

11:30｜去一个适合拍照但不拥挤的街区散步，路线控制在 1.5 小时以内

13:00｜午餐选择当地特色但不用排长队的店

15:00｜咖啡馆或甜品店，作为休息和聊天时间

17:00｜回酒店整理、换衣服

19:00｜提前预约一顿有氛围的晚餐，当天的重点体验

21:00｜附近夜景散步，不再跨区移动

备注：这一天不是刷景点，是让两个人有舒服相处的时间。后续 5 天都按这种颗粒度和节奏来设计。

这一步价值很大。你不只是告诉模型"我要什么"，你还告诉它"什么样的输出算好"。它会模仿你的颗粒度、节奏和审美。

之前它可能写："下午游览新宿，晚上品尝美食。"现在它会写："下午 15:00 到 16:30，安排咖啡馆或甜品店作为休息点，不再塞景点；晚上 19:00 预约氛围感晚餐，当天不安排远距离转场。"

从"列清单"变成了"设计体验"。

第 4 步：要求结构化输出

让它按固定结构输出：

请用统一结构输出，每天包含：

当日主题

上午安排：时间、地点、交通、体验重点

下午安排：时间、地点、休息点、拍照点

晚上安排：晚餐建议、夜间活动、是否需要预约

预算估算：交通、餐饮、门票、住宿均摊

当日风险：排队、天气、交通、体力

Plan B：如果下雨或临时太累，怎么调整

情侣体验点：这一天有什么适合两个人共同记住的细节

结构化输出有两个作用。第一，好读，不用从大段文字里找重点。第二，逼模型想得更完整------当你要求它每天写"预算估算""当日风险""Plan B""情侣体验点"，它就不太容易只给你一份景点堆叠清单。它会被迫考虑：这一天会不会太累？下雨怎么办？有没有需要提前预约？有没有两个人共同的体验重点？

让模型有一个稳定的输出骨架，比让它自由发挥靠谱。

第 5 步：先做规划原则和检查清单，再给答案

以前大家喜欢说"让模型展示思维链"。但在实际产品里，更好的做法不是让它把内心推理全写出来，而是要求它输出可检查的规划原则、筛选标准和自检结果：

在输出最终行程前，请先完成以下规划检查：

列出这次情侣日本旅行的设计原则

按城市或区域分组，避免每天来回折返

每天控制 2 到 3 个主要地点

检查每天是否有休息点、晚餐安排和 Plan B

检查 5 天总预算是否接近 2 万

如果某天过满，主动删减，不要硬塞

最后再输出结构化行程

这一步让结果更稳。模型不再直接跳到答案，而是先想清楚"什么是好方案"：这不是打卡旅行，是情侣体验；每天要有一个主题，不是乱排；浪漫不是每天都吃贵餐厅，是节奏、空间、留白和细节；预算不是最后随便写个数，是每天都要控制。

到这里，Prompt Engineering 基本发挥到了比较高的水平。你能得到一份在"静止世界"里相当不错的旅行方案。

但它很快会撞到三堵墙。

Prompt 的三堵墙

第一，所有信息都要你手动说。你忘了说"女朋友不喜欢早起"，它就可能安排早上 7 点出门。你忘了说"她不吃海鲜"，它就可能推荐寿司或海鲜市场。你忘了说"这是第一次一起出国"，它就不会主动安排更稳妥的节奏。

第二，它不知道真实世界的最新情况。某个展览还开不开，餐厅关没关门，门票卖没卖完，某条路有没有施工，它不一定知道。更糟的是，它不知道但会自信地编。

第三，它只能"说"，不能"做"。它可以建议你预约餐厅，但不会真帮你查有没有位。它可以估算交通时间，但没真调用地图。它可以说预算在 2 万以内，但不一定真算对。

Prompt 的极限是：把模型已经知道的、你已经告诉它的东西组织到最好。但它够不到两样东西------它不知道的，它做不到的。

这就需要 Context 和 Harness.

第二层：Context Engineering

不只是写 Prompt，而是决定"模型应该带着什么信息思考"

Context Engineering 经常被误解成"写更长的 Prompt"。不是。

Prompt 问的是：这段指令怎么写？Context 问的是：最终送进模型窗口里的整包信息，应该包含什么？从哪来？按什么顺序拼？哪些该放，哪些不该放？

在旅行例子里，Prompt 是你手写的那套要求。Context 会把更多信息自动塞进来：你的日历、航班时间、酒店地址、你和女朋友的偏好、历史旅行反馈、实时检索到的开放时间、票务情况、天气、交通、你们收藏过的餐厅咖啡馆展览。

最终送给模型的不再只是一句"帮我规划日本 5 天旅行"，而是一整包动态上下文：

任务：日本 5 天情侣旅行

Prompt：

你是定制旅行规划师
目标是轻松、浪漫、不特种兵
输出结构化行程
检查预算、节奏、Plan B

个人上下文：

用户和女朋友都不喜欢太早起
女朋友喜欢拍照、咖啡馆、安静街区
两人希望每天有自由时间
预算约 2 万

实时上下文：

航班抵达时间
酒店具体位置
当前天气趋势
景点开放时间
餐厅是否需要预约
交通耗时

Context 不替代 Prompt，它把 Prompt 包起来。Prompt 仍然是骨架，但信息来源不再全靠你手动输入。

Context 动作 1：把"写死的约束"换成"自动接入的数据"

在 Prompt 阶段，你必须手动写：我和女朋友不喜欢早起，预算 2 万，想住交通方便的地方，她喜欢拍照和咖啡馆，不想每天行程太满。

如果做成 Context，这些信息可以来自不同数据源。日历里有出发日期和请假时间，邮箱或订单里有航班和酒店，地图收藏里有她想去的咖啡馆，聊天记录或旅行笔记里有"上次行程太赶，吵了一架"这种重要反馈，长期记忆里有"你们更喜欢松弛旅行，不是景点刷满"。

这样，你只说一句"帮我规划日本 5 天"，系统也能自动补全很多关键信息。

这就是从"人每次重复交代"到"系统自动带入背景"。

Context 动作 2：用检索补上模型不知道的实时事实

旅行计划最怕过期信息。模型可能知道某个地方热门，但不知道现在开不开放；知道某家餐厅有名，但不知道最近搬没搬、停没停业、变没变得很难约；建议某个展览，但不知道你去的那几天是否闭馆。

Context 需要在生成前先检索：景点当前开放时间，餐厅是否营业、是否需要预约，展览是否仍举办，交通路线是否顺畅，天气是否适合户外，近期游客反馈有没有明显的坑。

这些信息拼进 Context，再交给模型。于是模型不是凭印象排，而是基于"现在的真实世界"排。

从"听起来合理"到"更接近真实可用"。

Context 动作 3：用 Memory 留住长期的你们

一次旅行里，有些约束是临时的：这次去日本，这次 5 天，这次预算 2 万，这次想住东京或大阪附近。

但有些偏好是长期的：你们不喜欢赶路，女朋友不喜欢太早起，你喜欢把餐厅提前定好，她喜欢下午有咖啡和拍照时间，你们旅行时更在意体验而不是景点数量。

这些东西不应该每次都重新说。Memory 的作用就是把这些长期稳定的信息存下来，下次相关任务自动调出。下次不去日本，去韩国、泰国、欧洲，系统依然知道：这不是一个"景点越多越好"的用户，是一个"要考虑两个人相处体验"的用户。

Prompt 是单次对话内的指令，Memory 让系统开始拥有跨任务、跨会话的连续性。

Context 动作 4：动态拼装，不是把所有信息都塞进去

Context 不是越多越好。你有十年旅行记录、上百个收藏地点、几千条聊天偏好，不可能全塞给模型。

真正的 Context Engineering 要做筛选。这次是"和女朋友去日本"，系统应该优先调出：情侣旅行相关偏好，日本相关历史记录，你们对住宿、餐饮、节奏的要求，近期天气和开放时间，本次预算相关信息。不应该把你出差的酒店偏好、公司会议日程、无关城市收藏全塞进去。

Context 的工程难点就在这里：不是有没有信息，而是能不能在正确的时间，把正确的信息，以正确的格式，放到正确的位置。

加上 Context 后，效果变成什么样？

同样一句"帮我规划日本 5 天旅行"。

Prompt 版本可能输出："建议第一天东京市区，第二天浅草和涩谷，第三天去京都，第四天大阪，第五天购物返程。"

Context 版本更像：

你们第一天晚上才落地，不安排跨城移动，只在酒店附近吃晚餐和散步。女朋友不喜欢早起，第二天从 10:30 开始。你们之前反馈过"每天换城市太累"，这次建议只做东京加近郊，不做东京、京都、大阪三城连跳。你们收藏过几家咖啡馆，放在下午休息段。预算 2 万，安排一顿有仪式感晚餐，其余餐饮控制在中档价位。

这不是普通攻略了。它开始像一个认识你们的人在做规划。

但 Context 仍然有墙。它能把信息带进来，不代表真的完成了任务。

Context 的墙

第一，它拿到的是某一刻的信息快照。检索到某家餐厅"看起来可以预约"，但没有真完成预约。

第二，它仍然主要在生成文本。可以建议你买票，但不会真的下单。可以说"这段路约 30 分钟"，但没有工具调用时那只是文本估算。

第三，它不会自然形成闭环。某家店满了，不会自动重排。预算超了，不会自动砍。某天路线被地图验证太绕，不会自己重新规划。

这就进入第三层：Harness。

第三层：Harness / Prompt Harness

给模型装上手脚、仪表盘和刹车

Harness 可以理解成"承载 AI Agent 的运行外壳"。有人也叫 Prompt Harness，容易让人误以为还是某种 Prompt 技巧。实际上 Harness 的重点不是 Prompt 写得更长，而是把 Prompt 和 Context 放进一个可以运行的系统里。

这个系统通常包括：工具调用、任务状态、多轮循环、结果验证、错误重试、人工确认、权限控制、日志记录、最终交付。

Prompt 是"怎么说"，Context 是"带着什么信息说"，Harness 是"怎么真的把事办完"。

Harness 动作 1：工具不只是拿资料，而是变成手脚

在 Context 里，工具更多是"读"------查开放时间、查天气、查餐厅信息，把结果放进上下文。

在 Harness 里，工具要变成"行动能力"。调用地图，实际计算酒店到每个地点的交通时间；调用日历，检查哪天能出发；调用票务系统，查是否有票；调用预订系统，查餐厅是否有位；调用预算表，真实加总花费；调用邮件或文档，把最终行程整理成可分享版本。

关键差别：Context 让模型知道更多，Harness 让模型能做更多。

Harness 动作 2：用 Loop 让 Agent 进入"感知---决策---行动---再感知"

Loop 是 Agent 的心脏。没有 Loop，模型就是一次性回答。有了 Loop，模型才像是在完成任务。

一个旅行规划 Agent 的 Loop 可能是这样：

感知：读取任务、用户偏好、日期、预算、航班、酒店
决策：生成粗略行程
行动：调用地图检查每天路线是否合理
观察：发现第 3 天跨区太多，交通时间过长
决策：删掉一个低优先级地点，换成附近活动
行动：查询晚餐预约
观察：目标餐厅无位
决策：找同类型、同预算、同区域的替代餐厅
行动：重新检查预算
观察：总预算超出
决策：调整一晚住宿或减少一顿高价餐
验证：全部达标后输出最终方案

这才是 Agent 行为------一边做，一边看结果，一边修正。不是一次回答。

Harness 动作 3：把"自查"变成真实 Eval

Prompt 里我们会写"检查预算是否超过 2 万""检查每天是否太累""检查路线是否合理"。但这类检查只靠模型自己说，不稳。它可能算错，也可能嘴上说"路线合理"，实际地图一查要转三次车。

Harness 里要变成真正的 Eval------评估门禁。情侣日本旅行可以设这些检查项：总预算是否超过 2 万，每天主要地点是否超过 3 个，每天是否有至少一个休息段，是否有一到两顿有仪式感的晚餐，是否避免连续多天早起，是否有雨天 Plan B，是否存在交通时间明显过长的安排，是否每天都有一个适合两个人共同体验的重点而不是纯打卡。

这些检查不是最后写一句"已满足"就完了，是系统真的拿数据去验证。预算用程序加总，交通用地图工具算，预约用真实返回结果看。不达标就打回重排。

很像软件工程里的 CI/CD：不是开发者说"我觉得没问题"，是测试和门禁跑过了才放行。

Harness 动作 4：护栏、权限和人工确认

当 Agent 真的能动手时，风险也变大。给错建议最多是答案不好，但真帮你订错酒店、买错票、把预算刷爆，那就是事故。

所以 Harness 必须有护栏。涉及付款前必须人工确认，涉及女朋友个人信息时必须经过授权，不确定时不能硬编要停下来问，API 返回异常时要重试或换数据源，超过循环次数要停止不能无限改计划，两个目标冲突时（比如"预算很低"但"每晚都要高级餐厅"）要明确提示取舍。

Harness 的成熟度，很多时候不在于能不能调用工具，而在于什么时候不该调用工具，什么时候必须让人介入。

加上 Harness 后，最终效果变成什么？

同样一句"帮我规划一下日本 5 天，和女朋友去，预算 2 万，别太赶。"

Prompt 版本给你的是一份"看起来不错的行程"。Context 版本给的是一份"结合你们偏好和实时信息的行程"。

Harness 版本可能是：

我已经根据你们的航班、酒店、预算和偏好生成了 5 天行程。第一天落地较晚，只安排酒店附近晚餐和散步。第二天原计划的展览票已售罄，替换为同区域另一个室内活动。第三天原路线地图验证后交通时间过长，已减少一个地点并加入下午休息段。第四天晚餐有两个可预约选项，价格分别为 A 和 B，需要你确认后再预订。当前预算估算 1.86 万，未超过 2 万。涉及付款的项目已暂停，等待你确认。

这不再是一篇攻略，已经接近一个能交付结果的系统。

四个词的最终对照

Prompt：告诉模型这次任务怎么做。决定模型的表达方式、任务边界、输出结构和思考方向。

Context：告诉模型这次任务需要知道什么。把用户背景、实时信息、历史偏好、外部资料动态拼进来。

Harness / Prompt Harness：让模型在一个可运行的系统里工作。负责工具调用、任务状态、验证、重试、权限、日志和交付。

Loop：让 Agent 不再一次性回答，而是反复执行"观察结果 → 做决定 → 采取行动 → 检查结果"。是 Agent 从聊天机器人变成任务执行者的关键。

一句话：Prompt 决定它怎么想，Context 决定它带着什么想，Harness 决定它能不能真的做完，Loop 决定它能不能边做边改。

补充：如果同行对象从女朋友换成父母，每个地方要改什么？

这一节能说明为什么 Prompt、Context、Harness 不是在解决同一个问题。

同一个"日本 5 天旅行"，对象从女朋友换成父母，表面看只是换了同行人，实际上整个系统的关注点都变了。和女朋友旅行，核心是体验、氛围、节奏、共同记忆。和父母旅行，核心变成舒适、安全、体力、饮食、少折腾。

Prompt 层要改什么？

在纯 Prompt 阶段，你必须手动把大量内容改掉。

原来的 Prompt：

你是一位资深定制旅行规划师，尤其擅长情侣旅行。请为我和女朋友规划一份日本 5 天旅行，要求轻松、浪漫、有记忆点，预算 2 万，不要特种兵。

换成父母：

你是一位资深定制旅行规划师，尤其擅长带父母和长辈出行。请为我和父母规划一份日本 5 天旅行，要求慢节奏、少换乘、少步行、饮食稳妥、方便休息，预算 2 万，不要特种兵。

需要改的地方：

模块	女朋友版本	父母版本
角色设定	情侣旅行规划师	长辈 / 家庭旅行规划师
旅行目标	浪漫、拍照、松弛、有记忆点	舒适、安全、少累、少折腾
节奏约束	每天 2 到 3 个地点，留咖啡和散步时间	每天 1 到 2 个重点地点，中午或下午必须休息
饮食偏好	有氛围、好吃、可安排一两顿仪式感晚餐	口味稳定、少生冷、少排队、座位舒适
交通要求	少折返即可，可以接受适度城市散步	少换乘、少楼梯、优先电梯、必要时打车
输出结构	情侣体验点、拍照点、晚餐氛围、Plan B	步行量、休息点、厕所/座椅、换乘难度、医疗/药店备选
检查清单	是否浪漫、是否有自由时间、是否适合两个人相处	是否太累、是否排队、是否有生食、是否方便休息

在 Prompt 层，改对象很麻烦。所有约束都写死在 Prompt 里，换一个同行人就得手动重写角色、目标、约束、示例、输出格式和检查标准。灵活，但依赖人每次说清楚。

Context 层要改什么？

到了 Context 层，你不一定要手动重写整段 Prompt，而是把"同行对象"这个变量换掉：

同行对象 = 女朋友 → 同行对象 = 父母

系统自动调出不同的上下文。

女朋友版本调出：她喜欢拍照，不喜欢早起，收藏过咖啡馆和小店，上次旅行觉得行程太赶，希望每天有聊天、散步和自由时间。

父母版本调出：父母年龄，能不能长时间步行，有没有膝盖腰椎血压等注意事项，吃不吃生食，要不要午休，是否偏好中餐熟食或清淡饮食，适不适合坐地铁换乘，是否需要住在离车站更近的酒店。

Context 层具体要换的：

Context 模块	女朋友版本	父母版本
个人偏好记忆	喜欢拍照、咖啡、安静街区、晚餐氛围	慢节奏、少走路、少楼梯、饮食稳妥
历史旅行反馈	上次太赶、某些城市街区很喜欢	上次走太多、排队太久、饭菜不适应
实时检索重点	展览、餐厅、拍照街区、天气、预约	电梯、无障碍路线、座椅、厕所、排队、交通换乘
动态拼装策略	优先拼入情侣体验相关信息	优先拼入体力、安全、饮食和交通信息
风险信息	下雨影响拍照、餐厅订不到、行程不够浪漫	走路过多、换乘复杂、没有座位、餐厅不合口味

区别出来了。Prompt 层你要手动把"情侣旅行"改成"父母旅行"。Context 层，系统根据"同行对象"自动调出不同信息。你不是重写整篇 Prompt，是在切换用户画像和任务上下文。变量变了，系统自动换背景。

Harness / Loop 层要改什么？

到了 Harness 层，变化更进一步。不只是换描述，是换执行策略、验证标准和失败处理方式。

女朋友版本的 Harness：查餐厅是否有位，查展览是否有票，检查每天是否有适合拍照和散步的时间，检查预算是否超标，目标餐厅没位就找同风格替代，下雨换室内展览或咖啡馆。

父母版本的 Harness：调用地图时不只查总耗时，还要查换乘次数、步行距离、是否需要大量上下楼；路线步行超过阈值自动改打车或换近一点的景点；餐厅需要排队自动剔除；景点没有足够休息点或路线太陡自动降级优先级；每天强制插入午休或回酒店休息时间；某天体力负担过高自动删减行程而不是塞 Plan B；天气太热太冷下雨优先切换到室内、少移动、可坐下的安排。

Harness 模块	女朋友版本	父母版本
工具调用	查餐厅、展览、拍照点、交通、预算	查步行距离、换乘次数、电梯、座椅、厕所、打车方案
Loop 策略	餐厅没位找同风格替代；下雨换室内体验	路线太累重排；排队太久剔除；没有休息点换地点
Eval 门禁	预算、氛围、自由时间、拍照体验	步数、换乘、楼梯、饮食安全、休息、医疗备选
人工确认	付款前确认、惊喜安排可选确认	高强度行程确认、远距离移动确认、费用明显增加时确认
失败处理	保持体验感，找相似替代	优先降低风险，宁可少玩也不要累坏

这就是 Harness 的核心：不是把"女朋友"三个字换成"父母"三个字，是把整个执行系统的判断标准都换掉。

对女朋友旅行，"少一点景点、多一点氛围"是好方案。对父母旅行，"少一点景点、多一点休息"才是好方案。表面都叫"不要特种兵"，系统里的含义完全不同。

Prompt 只能靠你写清楚。Context 能帮你自动带入背景。Harness 能把这些背景落实成工具调用、评估门禁和重排循环。

这个对照说明了什么？

从"女朋友"换成"父母"，三层能力的差异很清楚了。

Prompt 层，变化靠手改。你要改角色、约束、示例、输出结构、检查清单。漏改一个地方，模型就可能混用旧标准。

Context 层，变化靠调取。你只要告诉系统同行对象变了，它自动拿出父母相关的偏好、身体条件、饮食要求、历史反馈和实时风险信息。

Harness 层，变化靠策略切换。系统不仅知道对象变了，还会改变怎么查、怎么验、怎么重排、什么时候停下来问你。

这就是进化的真正好处：不是让 Prompt 变得更长，而是把"任务变化"从手工改词，升级成系统自动换上下文、换工具策略、换验证标准。

最终，成熟的 Agent 不该只是会写一份漂亮行程。它应该知道：和女朋友去，日本旅行的重点是体验和关系；和父母去，日本旅行的重点是舒适和安全。同样一句"帮我规划日本 5 天"，背后跑的是两套完全不同的上下文、检查标准和执行循环。

AI Agent 的进化，不是从短 Prompt 变成长 Prompt，是从"会回答"变成"懂背景、能行动、会验证、能修正"。