[{"data":1,"prerenderedAt":898},["ShallowReactive",2],{"article-/articles/engineering":3},{"id":4,"title":5,"author":6,"body":7,"category":883,"date":884,"description":14,"extension":885,"featured":886,"home_position":887,"image":888,"meta":889,"navigation":890,"order":891,"path":892,"seo":893,"status":887,"stem":894,"tags":895,"__hash__":897},"content/articles/Engineering.md","Engineering","sibuchen",{"type":8,"value":9,"toc":871},"minimark",[10,15,22,25,30,33,36,39,75,78,85,92,95,97,101,107,114,117,149,156,162,167,169,173,180,186,197,200,227,234,239,241,245,252,264,308,315,339,346,353,358,360,364,367,373,383,390,419,426,436,439,444,446,450,453,460,475,478,488,498,501,515,521,526,528,532,538,611,614,649,656,658,662,665,685,688,693,695,699,704,790,795,829,834],[11,12,14],"h1",{"id":13},"agent-的五层-engineering-架构","Agent 的五层 Engineering 架构",[16,17,18],"blockquote",{},[19,20,21],"p",{},"从「怎么说模型才答得对」，到「五个 Agent 怎么分工」——一个工程师真正要做的五件事。",[23,24],"hr",{},[26,27,29],"h2",{"id":28},"一先问一个问题agent-是用出来的还是造出来的","一、先问一个问题：Agent 是「用」出来的，还是「造」出来的？",[19,31,32],{},"2023 年，Shawn Wang（swyx）写了一篇被反复引用的《The Rise of the AI Engineer》，给这个新岗位定了个调：它既不是写提示词的 Prompt Engineering（太窄），也不是训练模型的 ML Engineering（太偏），而是「专门把 AI 落地成产品」的工程师。",[19,34,35],{},"到了 2025、2026，这个词的后缀悄悄变成了「Agent」。招人 JD 里开始出现 Agent Engineering，人们讨论的不再是「怎么让模型答得更好」，而是「怎么让一个（或一群）模型自动把事做完」。",[19,37,38],{},"但「让模型把事做完」这句话，拆开来看是一堆非常具体、非常工程化的问题：",[40,41,42,51,57,63,69],"ul",{},[43,44,45,46,50],"li",{},"提示词模板怎么写，模型才答得对？（",[47,48,49],"strong",{},"Prompt Engineering","）",[43,52,53,54,50],{},"该把哪些信息塞进上下文、哪些挡在门外？（",[47,55,56],{},"Context Engineering",[43,58,59,60,50],{},"模型干活的时候，怎么约束它、防住它的错、守住安全底线？（",[47,61,62],{},"Harness Engineering",[43,64,65,66,50],{},"一个 Agent 反复试的时候，什么时候继续、什么时候停下？（",[47,67,68],{},"Loop Engineering",[43,70,71,72,50],{},"多个 Agent 一起上的时候，怎么分工、怎么协作？（",[47,73,74],{},"Group Engineering",[19,76,77],{},"我把这五件事叫做「Agent 工程的五层」。坦白说：我在可检索的权威文献范围内并没有找到这五个词的任何原始出处——它们更像是一种归纳，而不是某个权威提出过的框架。但它们的每一层内容都有非常成熟的对应物：提示词工程、上下文工程、马鞍工程、循环工程、协调工程。",[19,79,80,81,84],{},"换句话说：",[47,82,83],{},"包装可能是新的，内容几乎都是旧的。"," 而这恰恰是最有意思的地方——Agent 时代真正稀缺的，从来不是新的魔法，而是把这些「旧」的工程纪律，用在对「非确定性系统」的驯化上。",[19,86,87],{},[88,89],"img",{"alt":90,"src":91},"","/assets/Engineer/sibuchen_%E6%80%BB%E8%B5%B7.jpg",[19,93,94],{},"下面一层一层拆。",[23,96],{},[26,98,100],{"id":99},"二prompt-engineering怎么说模型才答得对","二、Prompt Engineering：怎么说，模型才答得对",[19,102,103,104],{},"提示词工程听起来最「低级」，却是所有人都绕不开的第一层。官方定义很朴素：",[47,105,106],{},"以可复现的方式，写出让模型持续满足要求的指令。",[19,108,109,110,113],{},"这句话的关键词是「可复现」和「持续」。所以 Anthropic 和 OpenAI 的官方文档在教你任何技巧之前，先要求你做三件事：",[47,111,112],{},"定义清楚的成功标准、一套能实测的评估方法、一个第一版草稿提示词。"," 没有这三样，任何「优化」都是拍脑袋。",[19,115,116],{},"然后是几条经过反复验证的「心法」：",[40,118,119,125,131,137,143],{},[43,120,121,124],{},[47,122,123],{},"新员工隐喻","：把模型当作一个聪明、但完全不了解你工作规范的新员工。你不说清楚，它就只能猜。",[43,126,127,130],{},[47,128,129],{},"同事测试","：把你的提示词拿给一个对任务毫无背景的同事，如果他困惑，模型也会困惑。这一条几乎能过滤掉九成烂提示词。",[43,132,133,136],{},[47,134,135],{},"示例比描述管用","：few-shot 是官方公认最可靠的「控制输出格式、语气、结构」的手段，3–5 个「相关、多样、结构化」的示例通常效果最好。",[43,138,139,142],{},[47,140,141],{},"查询放结尾","：长上下文场景下，把长文档放开头、把真正的问句放最后，响应质量可以提升最多 30%。",[43,144,145,148],{},[47,146,147],{},"思维链的反转","：老模型时代，手把手教 \"Let's think step by step\" 是神技；但对今天的前沿模型，一句泛化的 \"think thoroughly\" 常常优于手写分步计划——模型自己的推理，经常超过你能预设的步骤。",[19,150,151,152,155],{},"还有一个容易被忽略的「坑」：",[47,153,154],{},"提示词会过时。"," 为老模型设计的 \"CRITICAL: You MUST use this tool...\"，到了新模型上会变成「过度触发」——模型疯狂调用不该调的工具。官方甚至专门开了一节「Remove over-prompting」。",[19,157,158,159],{},"Prompt Engineering 的真正成熟标志，是把提示词从一个「文本」变成一件「软件制品」：变量化模板、版本化进代码仓库、复用型指令下沉到 CLAUDE.md 或 skills、由 eval 套件守护回归。",[47,160,161],{},"一个被版本管理和 eval 守护的提示词，才算工程；一个飘在聊天框里的提示词，只是运气。",[19,163,164],{},[88,165],{"alt":90,"src":166},"/assets/Engineer/sibuchen_PromptEngineer.jpg",[23,168],{},[26,170,172],{"id":171},"三context-engineering给模型看什么比怎么写更重要","三、Context Engineering：给模型看什么，比怎么写更重要",[19,174,175,176,179],{},"Anthropic 在 2025 年抛出了一个很有分量的说法：",[47,177,178],{},"Prompt Engineering 其实是 Context Engineering 的一个子集。"," 后者管的是更根本的问题——在采样时，喂给模型的那组 token 到底该怎么选。",[19,181,182,183],{},"核心原则一句话：",[47,184,185],{},"找到能最大化目标结果的最小高信号 token 集合。",[19,187,188,189,192,193,196],{},"为什么「最小」这么重要？因为有个被反复验证的现象叫 ",[47,190,191],{},"context rot","：上下文里的 token 越多，模型准确回忆信息的能力越差。每一块新塞进来的信息，都在消耗有限的注意力预算。还有那篇著名的《Lost in the Middle》论文：模型对长上下文",[47,194,195],{},"中间位置","的信息利用最差，重要证据放在开头或结尾效果最好——一条 U 型曲线。所以「把检索到的段落一股脑塞进去」是错的，你得把重要的挪到两端。",[19,198,199],{},"这直接引出了 Context Engineering 日常要做的四个决定：",[201,202,203,209,215,221],"ol",{},[43,204,205,208],{},[47,206,207],{},"检索还是全量塞？"," 一个很实用的阈值：知识库小于约 20 万 token（约 500 页），全量放进 prompt 更简单；更大才上 RAG。配上 prompt caching（缓存读取比基础输入便宜 90%），「全量入上下文」的成本可以低到惊人。",[43,210,211,214],{},[47,212,213],{},"RAG 怎么做得更好？"," 一个立竿见影的招是 Contextual Retrieval：给每个 chunk 前置一句 50–100 token 的背景说明，再结合重排序，检索失败率能从 5.7% 降到 1.9%——降幅 67%。",[43,216,217,220],{},[47,218,219],{},"长任务怎么不爆上下文？"," 四个机制：compaction（高保真压缩后重开窗口）、结构化笔记/外部记忆（把状态写到上下文之外，比如一个 progress 文件）、sub-agent（大量探索只回传 1000–2000 token 的精炼摘要）、以及清理历史工具原始输出。",[43,222,223,226],{},[47,224,225],{},"什么时候按需加载？"," just-in-time 检索：只保留轻量标识符（文件路径、查询、链接），运行时按需拉取，而不是预先把一切塞进去。Claude Code 就是这种混合策略——CLAUDE.md 前置，glob/grep 按需。",[19,228,229,230,233],{},"如果说 Prompt Engineering 管的是「措辞」，Context Engineering 管的则是「",[47,231,232],{},"信息经济学","」：每一块 token 都有成本，也都有（可能是负的）收益。给模型看什么，往往比让它怎么说更重要。",[19,235,236],{},[88,237],{"alt":90,"src":238},"/assets/Engineer/sibuchen_ContextEngineer.jpg",[23,240],{},[26,242,244],{"id":243},"四harness-engineering给模型套上一个不会犯错的壳","四、Harness Engineering：给模型套上一个不会犯错的壳",[19,246,247,248,251],{},"Harness 这个词直译是「挽具/外骨骼」，我更喜欢叫它「运行底座」。Anthropic 给过一个很漂亮的定义：",[47,249,250],{},"工具是「确定性系统与非确定性 Agent 之间的契约」。"," Harness Engineering 干的，就是把这个契约工程化。",[19,253,254,255,259,260,263],{},"最底层的骨架很简单：模型输出一个 ",[256,257,258],"code",{},"tool_use"," 块 → 你的代码执行工具 → 把结果放进 ",[256,261,262],{},"tool_result"," 回传 → 模型继续。但真正的功夫全在细节里：",[40,265,266,278,292,298],{},[43,267,268,271,272,274,275,277],{},[47,269,270],{},"协议约束","：",[256,273,262],{}," 必须紧跟对应的 ",[256,276,258],{},"，而且在消息数组里必须排在文本前面，否则直接 400 报错。这是最容易踩的坑。",[43,279,280,283,284,287,288,291],{},[47,281,282],{},"工具描述是命门","：官方说这是「决定工具性能的最重要因素」，每个工具至少写 3–4 句——做什么、何时该用不该用、每个参数什么意思、有什么限制。另一个反直觉的建议是「",[47,285,286],{},"合并而非细分","」：把 create/review/merge 三个工具合成一个带 ",[256,289,290],{},"action"," 参数的工具，模型选择反而更准。",[43,293,294,297],{},[47,295,296],{},"工具输出要截断","：模型上下文窗口有限，工具只返回高信号信息（语义化的标识符，而不是 UUID），Claude Code 默认把工具响应截在 25,000 token。",[43,299,300,303,304,307],{},[47,301,302],{},"防错前移","：给工具定义加 ",[256,305,306],{},"strict: true","，用 grammar-constrained sampling 保证模型输出的参数严格符合 JSON Schema，省掉运行时校验和重试。",[19,309,310,311,314],{},"然后是安全。Agent 世界最核心的威胁，是 2023 年被系统提出的 ",[47,312,313],{},"Indirect Prompt Injection","：攻击者把恶意指令藏进 Agent 随后会检索到的数据里，就能远程劫持它——因为「处理检索到的 prompt，相当于任意代码执行」。工程上的防线是一套组合拳：",[40,316,317,324,327,333,336],{},[43,318,319,320,323],{},"不可信内容",[47,321,322],{},"只放进 tool_result 块","，绝不进系统提示词或用户文本；",[43,325,326],{},"对不可信字符串做 JSON 编码，划清边界；",[43,328,329,332],{},[47,330,331],{},"最小权限","：Agent 能碰什么、能改什么，默认关到最小；",[43,334,335],{},"代码在沙箱里跑（无外网、文件限于工作目录）；",[43,337,338],{},"模型看到之前，先用轻量模型筛查工具输出。",[19,340,341,342,345],{},"至于 MCP（Model Context Protocol），它把「接工具」标准化了，但规范自己写得明白：",[47,343,344],{},"协议层无法强制安全，靠实现者落实。"," 工具调用前必须取得用户明确同意——这句写在规范里，但能不能落地，取决于写 harness 的那个人。",[19,347,348,349,352],{},"一句话总结这一层：",[47,350,351],{},"把非确定性核心，装进一个确定性外壳。"," 外壳负责约束、防错、安全；核心只负责「想」。",[19,354,355],{},[88,356],{"alt":90,"src":357},"/assets/Engineer/sibuchen_HarnessEngineer.jpg",[23,359],{},[26,361,363],{"id":362},"五loop-engineering什么时候继续什么时候停下","五、Loop Engineering：什么时候继续，什么时候停下",[19,365,366],{},"单 Agent 的迭代循环，是 Agent 区别于「一次调用」的本质。它的原型是 2022 年的 ReAct：模型交替产出「推理」和「行动」，用环境返回的「观察」修正下一步。后来又有了 Reflexion——不更新权重，而是让 Agent 口头反思、把教训存进记忆，下一次试的时候引以为戒。",[19,368,369,370],{},"但 Loop Engineering 要回答的其实就两个问题：",[47,371,372],{},"继续，还是结束？",[19,374,375,376,379,380],{},"先说「什么时候不该用循环」：Anthropic 给了一条很清楚的判定线。如果任务的步骤数可预测、能硬编码，就用 ",[47,377,378],{},"workflow","（预定义代码路径）；只有面对「不知道要走几步」的开放问题，才上真正的自主循环。",[47,381,382],{},"别为了用 agent 而用 agent。",[19,384,385,386,389],{},"再说「怎么结束」：真实系统里的共识是——",[47,387,388],{},"停止条件必须有两层","。",[40,391,392,402],{},[43,393,394,397,398,401],{},[47,395,396],{},"语义层","：任务真的完成了（比如调用了 ",[256,399,400],{},"final_answer","，或输出被判定为最终结果）。",[43,403,404,407,408,411,412,415,416,389],{},[47,405,406],{},"机械层","：一个硬性的迭代上限。smolagents 用「最大步数」，OpenAI Agents SDK 用 ",[256,409,410],{},"max_turns","（超限直接抛异常），LangGraph 用 ",[256,413,414],{},"recursion_limit","（当前默认 10007）。这一层是保险丝，",[47,417,418],{},"不依赖模型自觉",[19,420,421,422,425],{},"为什么保险丝这么重要？因为真实系统里排名第一的失败模式，恰恰是「",[47,423,424],{},"该停不停","」：Anthropic 的多 Agent 系统上线初期就发现 Agent「明明结果已经够了还在继续」；Chip Huyen 则点出另一种反面——「虚假完成」，Agent 以为自己做完了，其实没有。",[19,427,428,429,432,433],{},"所以成熟的 Loop Engineering 还会做一件事：",[47,430,431],{},"给 Agent 一个能自我验证的 check。"," Karpathy 说过，一个任务「可不可验证」，是它能不能被强化学习优化的最具预测性的特征。落到工程上就是 Claude Code 官方最佳实践的第一条：给它一个能跑的测试、一个能对比的构建或截图——",[47,434,435],{},"这是你「全程盯着」和「放心走开」之间的区别。",[19,437,438],{},"循环的智慧，一半在于知道何时继续，另一半在于知道何时必须停下。",[19,440,441],{},[88,442],{"alt":90,"src":443},"/assets/Engineer/sibuchen_LoopEngineer.jpg",[23,445],{},[26,447,449],{"id":448},"六group-engineering让多个-agent-分工而不是让它们开会","六、Group Engineering：让多个 Agent 分工，而不是让它们开会",[19,451,452],{},"当一个问题真的太大、太可并行、或者要对接的工具太多，单个 Agent 的上下文和精力就不够了。这时候轮到 Group Engineering 上场。",[19,454,455,456,459],{},"主流架构是 ",[47,457,458],{},"orchestrator-worker（主从）","：一个 lead Agent 做规划，把子任务并行派发给 3–5 个子 Agent，每个子 Agent 有独立的目标、输出格式、工具和任务边界，干完只回传一份压缩后的结论。这本质上是一种「关注点分离」——每个子 Agent 守着自己的上下文窗口。",[19,461,462,463,466,467,470,471,474],{},"其他模式也存在：AutoGen 式的",[47,464,465],{},"群聊","（选一个发言者、广播给所有人，对等去中心化）、源自 1980 年代语音识别系统的",[47,468,469],{},"黑板架构","（共享状态而非消息传递）、以及 OpenAI Agents SDK 里的 ",[47,472,473],{},"handoffs","（路由后把会话控制权转交给专家 Agent）。",[19,476,477],{},"但这一层最该记住的，反而是两条「劝退」：",[19,479,480,483,484,487],{},[47,481,482],{},"第一，多数任务不需要多 Agent。"," Anthropic 反复强调：先试「单个 Agent + 良好的上下文工程」，只有任务",[47,485,486],{},"高度可并行、信息超单上下文窗口、或要对接大量复杂工具","时，多 Agent 才真正划算。多数编码任务因为可并行的子任务少、LLM 又不擅长实时协调，反而不适合多 Agent。",[19,489,490,493,494,497],{},[47,491,492],{},"第二，多 Agent 的价值本质，要想清楚。"," Anthropic 自己披露过一组数据：他们的多 Agent 研究系统比单 Agent 提升 90.2%，但比聊天多花约 15 倍 token，而且「token 用量单独解释了 80% 的性能方差」。这组数字（注意：是厂商自报的内部评估）其实指向一个有点反高潮的结论——",[47,495,496],{},"多 Agent 的有效，很大程度是「有组织地多烧算力」，而不是协作本身有什么魔法。"," 换句话说，如果你用同样的 token 预算喂给一个「多步思考 + 工具」的单 Agent，增益未必差多少。",[19,499,500],{},"所以 Group Engineering 真正要管理的，不是「怎么让 Agent 聊天」，而是两件更工程化的事：",[40,502,503,509],{},[43,504,505,508],{},[47,506,507],{},"错误传播","：Agent 是有状态的，错误会复利，一步走偏会把整条轨迹带进沟里。缓解手段是从错误点恢复而非从头重启、重试、checkpoint。",[43,510,511,514],{},[47,512,513],{},"规模控制","：把「努力程度」显式编码进 prompt——简单查证派 1 个 Agent、3–10 次工具调用；复杂研究才派 10+ 个子 Agent。早期的坑就是简单查询派了 50 个子 Agent，纯粹浪费。",[19,516,517,518],{},"一句话：",[47,519,520],{},"让 Agent 分工，是为了把问题切成能独立完成的块，不是为了开一场谁也不会结束的会。",[19,522,523],{},[88,524],{"alt":90,"src":525},"/assets/Engineer/sibuchen_GroupEngineer.jpg",[23,527],{},[26,529,531],{"id":530},"七把它们串起来五层其实是一条线","七、把它们串起来：五层其实是一条线",[19,533,534,535,389],{},"讲完五层，回头看一眼，会发现它们不是五件事，而是同一件事的五个切面——",[47,536,537],{},"驯化非确定性",[539,540,541,557],"table",{},[542,543,544],"thead",{},[545,546,547,551,554],"tr",{},[548,549,550],"th",{},"层",[548,552,553],{},"核心问题",[548,555,556],{},"一句话心法",[558,559,560,571,581,591,601],"tbody",{},[545,561,562,565,568],{},[563,564,49],"td",{},[563,566,567],{},"怎么说才答得对",[563,569,570],{},"让提示词成为被 eval 守护的软件制品",[545,572,573,575,578],{},[563,574,56],{},[563,576,577],{},"该看哪些信息",[563,579,580],{},"上下文是首要资源，选最小高信号集合",[545,582,583,585,588],{},[563,584,62],{},[563,586,587],{},"怎么约束防错安全",[563,589,590],{},"确定性外壳，包住非确定性核心",[545,592,593,595,598],{},[563,594,68],{},[563,596,597],{},"何时继续何时停",[563,599,600],{},"完成判定之外，永远有一根机械保险丝",[545,602,603,605,608],{},[563,604,74],{},[563,606,607],{},"怎么分工协作",[563,609,610],{},"先证明需要多个，再谈怎么分工",[19,612,613],{},"贯穿始终的，还有三条跨层的纪律：",[201,615,616,622,640],{},[43,617,618,621],{},[47,619,620],{},"简单优先","：能用一次 LLM 调用解决的就别上 Agent，能用单 Agent 解决的就别上多 Agent。复杂度只有在「被 eval 证明能改善结果」时才允许增加。",[43,623,624,627,628,631,632,635,636,639],{},[47,625,626],{},"eval 先行","：建 Agent 之前先建评估集。这里有个漂亮的指标分裂值得记住——",[256,629,630],{},"pass@k","（k 次里至少一次成功）和 ",[256,633,634],{},"pass^k","（k 次全部成功）在 k=10 时讲的是",[47,637,638],{},"完全相反的故事","：前者逼近 100%，后者跌到 0%。前者适合「演示」，后者才是「生产可靠」。选错指标，是很多 Agent 产品「演示惊艳、上线翻车」的根源。",[43,641,642,645,646],{},[47,643,644],{},"承认不确定性","：就像这篇文章开头坦白的，五层分类法是归纳而非既有框架，而且这个领域最权威的证据高度集中在少数几家模型厂商手里——它们同时是「卖 token」的人。一个真正的工程师，在采信任何一条「共识」之前，都该问一句：",[47,647,648],{},"谁在定义这个词，谁在从中受益？",[19,650,651,652,655],{},"这第三点，或许是「Agent 与 Engineering」这个题目最想说的话：",[47,653,654],{},"Agent 时代最稀缺的，不是会调 API 的人，而是能把一个非确定性系统，用工程纪律一点点驯服的人。"," 那份对「共识」保持怀疑、对「数字」要求出处、对「简单」心怀敬畏的克制，本身就是工程师这个职业最值钱的部分。",[23,657],{},[26,659,661],{"id":660},"八结语从今天可以动手的三件事","八、结语：从今天可以动手的三件事",[19,663,664],{},"如果你看完想立刻做点什么，从这三件开始，它们几乎零成本、却最难被替代：",[201,666,667,673,679],{},[43,668,669,672],{},[47,670,671],{},"给你手头最重要的一个 Agent 建一个 eval 集","——从 20–50 个真实失败案例起步，把失败变成回归测试。",[43,674,675,678],{},[47,676,677],{},"给它一个「能跑的 check」","——一个测试、一次构建、一张可对比的截图，让它自己验证自己。",[43,680,681,684],{},[47,682,683],{},"重新审视它的上下文","——删掉一块低信号 token，往往比再调一百次提示词更有效。",[19,686,687],{},"Agent 不会替你想清楚这些。想清楚这些的，是 Engineering。",[19,689,690],{},[88,691],{"alt":90,"src":692},"/assets/Engineer/sibuchen_%E7%BB%93%E8%AF%AD.jpg",[23,694],{},[26,696,698],{"id":697},"参考-延伸阅读","参考 / 延伸阅读",[19,700,701],{},[47,702,703],{},"官方文档与工程博客（Anthropic / OpenAI / 协议）",[40,705,706,716,724,731,739,747,755,763,770,777],{},[43,707,708,715],{},[709,710,714],"a",{"href":711,"rel":712},"https://www.anthropic.com/engineering/building-effective-agents",[713],"nofollow","Building Effective Agents"," — workflow/agent 定义、五模式、简单优先",[43,717,718,723],{},[709,719,722],{"href":720,"rel":721},"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents",[713],"Effective Context Engineering for AI Agents"," — context rot、上下文四机制",[43,725,726],{},[709,727,730],{"href":728,"rel":729},"https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents",[713],"Effective Harnesses for Long-Running Agents",[43,732,733,738],{},[709,734,737],{"href":735,"rel":736},"https://www.anthropic.com/engineering/multi-agent-research-system",[713],"Multi-Agent Research System"," — 90.2% / 15× / 80% 自报数据",[43,740,741,746],{},[709,742,745],{"href":743,"rel":744},"https://www.anthropic.com/engineering/writing-tools-for-agents",[713],"Writing Tools for Agents"," — 工具契约",[43,748,749,754],{},[709,750,753],{"href":751,"rel":752},"https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents",[713],"Demystifying Evals for AI Agents"," — pass@k vs pass^k",[43,756,757,762],{},[709,758,761],{"href":759,"rel":760},"https://www.anthropic.com/news/contextual-retrieval",[713],"Contextual Retrieval"," — 67% 降幅、200K 阈值",[43,764,765],{},[709,766,769],{"href":767,"rel":768},"https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices",[713],"Prompt Engineering Best Practices",[43,771,772],{},[709,773,776],{"href":774,"rel":775},"https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf",[713],"OpenAI: A Practical Guide to Building Agents (PDF)",[43,778,779,784,785],{},[709,780,783],{"href":781,"rel":782},"https://modelcontextprotocol.io/specification/2025-06-18",[713],"MCP Specification"," + ",[709,786,789],{"href":787,"rel":788},"https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices.md",[713],"MCP Security Best Practices",[19,791,792],{},[47,793,794],{},"学术",[40,796,797],{},[43,798,799,804,805,804,810,804,815,804,820,804,825],{},[709,800,803],{"href":801,"rel":802},"https://arxiv.org/abs/2201.11903",[713],"Chain-of-Thought"," · ",[709,806,809],{"href":807,"rel":808},"https://arxiv.org/abs/2210.03629",[713],"ReAct",[709,811,814],{"href":812,"rel":813},"https://arxiv.org/abs/2303.11366",[713],"Reflexion",[709,816,819],{"href":817,"rel":818},"https://arxiv.org/abs/2307.03172",[713],"Lost in the Middle",[709,821,824],{"href":822,"rel":823},"https://arxiv.org/abs/2005.11401",[713],"RAG",[709,826,313],{"href":827,"rel":828},"https://arxiv.org/abs/2302.12173",[713],[19,830,831],{},[47,832,833],{},"专家与业界",[40,835,836,843,850,857,864],{},[43,837,838],{},[709,839,842],{"href":840,"rel":841},"https://www.latent.space/p/ai-engineer",[713],"swyx: The Rise of the AI Engineer",[43,844,845],{},[709,846,849],{"href":847,"rel":848},"https://lilianweng.github.io/posts/2023-06-23-agent/",[713],"Lilian Weng: LLM Powered Autonomous Agents",[43,851,852],{},[709,853,856],{"href":854,"rel":855},"https://huyenchip.com/2025/01/07/agents.html",[713],"Chip Huyen: Agents",[43,858,859],{},[709,860,863],{"href":861,"rel":862},"https://simonwillison.net/2025/Nov/23/agent-design-is-still-hard/",[713],"Armin Ronacher: Agent Design is Still Hard",[43,865,866],{},[709,867,870],{"href":868,"rel":869},"https://hamel.dev/blog/posts/evals/",[713],"Hamel Husain: Evals",{"title":90,"searchDepth":872,"depth":872,"links":873},2,[874,875,876,877,878,879,880,881,882],{"id":28,"depth":872,"text":29},{"id":99,"depth":872,"text":100},{"id":171,"depth":872,"text":172},{"id":243,"depth":872,"text":244},{"id":362,"depth":872,"text":363},{"id":448,"depth":872,"text":449},{"id":530,"depth":872,"text":531},{"id":660,"depth":872,"text":661},{"id":697,"depth":872,"text":698},"agent","2026-08-31","md",false,null,"/images/Agent五大工程竖.png",{},true,5,"/articles/engineering",{"title":5,"description":14},"articles/Engineering",[896,5,6],"AIAgent","pjVyV7lm3sOcqbZiyU7Lh7W8bALW2O9R4oI8TiWK04o",1788191400458]