用于网页研究智能体的上下文工程与提示工程

摘要：

• 提示工程定义模型应执行的任务。 上下文工程决定应用为该任务提供哪些证据、工具和状态。
• 更清晰的指令无法提供不存在的来源页面。 进行网页研究的智能体需要获取路径和证据接纳策略。
• 搜索结果和来源证据回答的是不同的问题。 在把发现的 URL 当作某个论断的支撑前，要先保留该页面的实际段落。
• 新鲜度属于具体论断。 最近抓取的页面仍然可能描述旧的政策、版本或事件。

一个研究智能体可以严格遵守所有格式指令，却仍从过时页面作答。指令被正确理解了；只是证据不适合当前问题。

当这种失败需要被诊断时，“上下文工程 vs 提示工程”的区分就变得有用。修改措辞在模型误解任务时有帮助。修改来源选择、获取或上下文组装，在模型拿到的信息不完整或不合适时有帮助。一个网页研究流程需要两者兼备。

本对比聚焦于一个使用公共网页来源回答问题的智能体。Scrapeless 提供搜索和网页获取。你的应用决定接受哪些证据、包含多少，以及这些证据可以支持哪些结论。

什么是提示工程？

提示工程是为一次模型交互设计指令、示例、约束与输出要求。一个有用的研究提示会明确问题本身、所需证据、不确定性的处理方式以及期望的答案格式。

例如，可以要求智能体识别某个官方实现细节、保留支持该结论的来源，并区分文档中明示的行为和模型自己推断的内容。这些指令澄清了任务本身，也为评估者提供了可明确核查的内容。

提示可以指示应用去使用应用所暴露的工具。它不能凭空创造缺失的工具、赋予对受限来源的访问权，或让页面自动变得最新。那些职责仍然属于外层系统。

什么是上下文工程？

上下文工程是为模型在每一步所提供的信息环境的设计。对于网页研究，这个环境包括问题本身、选定来源、检索到的段落、相关工具定义以及未完成工作的状态。

应用在调用模型前，可能会先发现一个 URL、抓取它、绕过挑战页面，然后选取一个支持性的段落。它也可能在后续步骤中移除已经过时的观察。这些决策在不改变用户问题的前提下，改变了模型可用的材料。

检索增强生成（retrieval-augmented generation）将生成与检索到的信息结合起来。上下文工程在检索之外扩展了应用设计：选择有用证据、保留其身份，并决定何时应替换这些证据。

上下文工程 vs 提示工程一览

二者的区别在于各自改变的工程对象。指令告诉智能体要做什么；上下文组装决定当它执行时能使用哪些材料。

决策内容	提示工程	上下文工程
研究范围	陈述问题及排除项	选择符合该范围的来源
证据	要求对重要论断提供支撑	抓取并保留支持性段落
输出	描述所需的结构	提供要填充的字段和来源标识
新鲜度	要求获取最新信息	应用抓取与替换规则
工具	说明何时适用某个工具	暴露所需的操作与结果
缺失信息	告诉模型报告不确定性	保留缺失、失败与未解决的状态
评估	检查指令遵从度	检查证据覆盖率与来源适配性

这些层是重叠的。检索策略由软件实现，而提示解释如何使用它所交付的证据。若把它们当成竞争性投入，就会使工作流的一部分缺乏规范。

什么时候改提示才是正确修复？

当证据已经足够，而请求的行为仍不清晰时，修改提示才是合适的。重写指令前，先检查来源包。

假设智能体拿到的是一个直接回答问题的最新文档，却返回了一份宽泛的教程。这时应收窄问题、指出所需的实现细节，并指定如何呈现结果。来源获取路径可能已经足够好了。

另一类指令问题是含糊的比较。“找出最好的方法”让决策标准完全悬空。“比较这些方法，面向一个需要来源引用和受控采集范围的团队”则为模型提供了可用的任务。在使用复杂提示技巧前，先用普通语言定义好评价标准。
保持一小组具有代表性的问题。更改指令的同时保持已接受的证据不变。这有助于隔离改进究竟来自提示本身，而不是来自不同的来源抓取。

证据流水线在何时需要改变？

当模型缺少回答问题所需的材料时，就需要关注证据流水线。要求“准确”的指令无法让模型恢复一段从未被提供的文本。

常见情形包括：将搜索摘要片段当作完整文档使用、抓取了错误地区版本的页面，或者为一个当前产品问题选用了旧文章。看似合理的回答可以掩盖上述每一种获取错误。

检查实际的输入包。它是否包含相关段落？该段落是否属于预期来源？其范围是否与论断相同？输入包是否区分“页面不可用”和“页面确实不包含相关信息”？

修复那个具体的边界。当缺少的只是一个来源段落时，扩大全部上下文窗口很少是首要的有效行动。

从发现页和来源页构建 Web 上下文

Web 上下文始于一个针对问题的来源计划，接着是发现与页面获取。保持这些阶段相互独立，以免搜索结果在无意中被提升为证据。

Google Search API 为来源发现提供结构化的 Google 搜索结果。连同查询设置一起保存结果，然后选择与研究任务相关的 URL。Google Search 快速入门 定义了请求面。

Web Unlocker 为需要从目标 URL 获取响应的应用检索页面内容。使用 Web Unlocker 请求配置 获取当前字段。你的应用仍然需要判断返回的内容是否是预期来源，以及该段落是否回答了问题。

这些产品提供的是获取操作。它们不会自动确保某个段落是权威的、最新的或足够的。将这些检查纳入上下文构建器中。

Start Scraping with Scrapeless

使用 Scrapeless 强化你的网页抓取与自动化工作流！
立即注册即可获得 $5 免费额度 —— 无需信用卡。

现在就在 Scrapeless 控制台 领取你的免费额度。

Web 研究的前后对比示例

有用的对比会保持问题不变，只改变所提供的证据。考虑：“哪个响应头标识 Cloudflare Challenge Page，应用程序应该检查什么值？”

仅指令输入： 只提供问题和“简要回答并附带来源”的指令。模型也许会记得某个相关行为，但应用程序并未提供当前的支持性段落。要求引用并不能证明被引用的页面曾实际被抓取。

证据支撑的输入： 相同的问题、官方页面身份、其抓取上下文，以及描述该响应头的段落。当前的 Challenge Page 检测信号 是 cf-mitigated，其值为 challenge。该来源还将挑战响应的内容类型描述为 text/html。

Evidence-package field	Value or responsibility
Question	Identify the documented header and value
Source identity	Official Challenge Page detection page
Capture time	Store the actual acquisition time
Supporting passage	Header name, value, and response-type statement
Interpretation	Apply the statement to the response being inspected
Unknowns	Whether an intermediary preserves origin headers

这是一个证据设计示例，而不是准确性基准或模型执行记录。它展示了在补齐缺失来源后可以支持什么，并未声称取得了经过测量的改进，也没有展示经过认证的 Scrapeless 请求结果。

在每个回答背后保留来源

源出处将衍生答案与支撑该答案的材料及获取活动连接起来。溯源数据模型对实体、活动和责任主体（代理）作出了有用区分。

对于一个网页上下文包，应保留原始 URL、最终页面标识、捕获时间、相关段落和抽取规则。即使模型随后只接收到更短的摘录，也要保留完整的源记录。

将“观察”与“解读”分开。“此页面包含这一标题声明”是观察。“此集成将该标题暴露给客户端”则需要其自身的实现层面证据。模型不应因为两种表述听起来相关就把它们合并。

同时管理新鲜度与上下文大小

新鲜度管理在证据失去效用时进行替换；上下文预算则决定哪些仍然有用的证据进入下一步模型处理。两种策略都依赖具体任务。

HTTP 新鲜度和验证区分了已存储响应的“是否新鲜”和“该响应是否仍然有效”的校验。应用层证据存储需要在传输缓存之外，拥有自己与具体主张相关的策略。

将捕获时间与事件发生日期分开。新近抓取的公告可能描述的是一次历史发布。反过来，一个稳定的规范即便发布时间久远，仍可能保持相关性。

围绕当前活跃问题选择段落。从模型输入中移除重复导航、无关章节以及已被取代的观察，同时在存储中保留原始内容。让未解决的矛盾可见。悄然删除“不方便”的段落会让上下文包更短，却更不可信。

评估出错的那一层

评估时应区分：指令遵循情况、证据是否合适，以及答案是否得到支持。这些失败对应不同的工程应对措施。

失败类型	首先检查	有用的改动
来源正确，答案格式错误	提示与输出要求	明确请求的结构格式
答案看似合理，但缺乏支撑	证据包	检索所需的源文段
答案描述的是旧版本	来源范围与新鲜度	替换或限定该观察
两个来源互相矛盾	溯源和解读	保留分歧并收窄结论主张
工具结果包含无关内容	获取与接收规则	拒绝不合适的结果

保留那些代理必须报告证据缺失的示例。一条总能给出“完整答案”的工作流，可能会掩盖失败而非使其可被处理。将这种评估设计与网页上下文自建或采购比较结合起来加以扩展。

结论

提示工程与上下文工程关注的是网页调研代理的不同部分。清晰的指令定义要完成的工作。受控的证据管线则提供执行该工作所需的来源、状态与工具结果。

从一个具有代表性的问题出发，检查实际的源上下文包。当任务不清晰时修改提示；当所需证据缺失时则修改获取或上下文组装方式。

准备好构建一个有源支撑的调研工作流了吗？

在 Scrapeless 中结合来源发现与页面获取，然后根据当前定价来评估已接受的证据。通过 Telegram 与开发者社区讨论你的工作流。

常见问题

问：上下文工程会取代提示工程吗？

上下文工程不会取代提示工程。一个调研代理既需要有用的证据，也需要关于如何解读和呈现这些证据的清晰指令。

问：更好的提示能否让模型访问实时网页？

只有在外部应用提供了相应的网页工具时，提示才能请求调用该工具。提示本身既不会创建获取服务，也不会凭空提供尚未返回的页面。

问：搜索摘要是否足以作为调研答案的证据？

搜索摘要可以支持来源筛选，但当主张依赖于页面的实际内容时，它们不应替代对完整页面的检查。

问：代理应如何处理过时信息？

代理应保留来源的范围和日期，应用应用程序自己的新鲜度策略，并替换或限定那些已不再支持当前问题的信息。

问：Scrapeless 对上下文工程有什么贡献？

Scrapeless 提供搜索和页面获取操作。你的应用程序负责证据筛选、来源溯源、验证、上下文组装，以及对最终答案的评估。

问：更大的上下文窗口能保证更好的答案吗？

更大的上下文窗口会增加可用的输入容量，但并不能确保所选证据是相关的、最新的或被正确解读的。