125分热帖刷屏!AI Agent自动化工具:6问告别神Prompt

你好，欢迎关注「AI工程手记」。

这里主要分享 AI 工程、Agent、自动化工作流和开源项目实战。

不讲太多概念，重点是怎么做、怎么用，趟过哪些坑。

今天聊上下文工程：少一点玄学，多一点可控。

先说结论：

过去一年，很多团队把时间花在“有没有一条神 Prompt”上，结果越写越长、越调越玄，最后谁也说不清到底哪一句真有用。

Claude 5 官方把“上下文工程”推到台前，就是来解决这个的。

它提醒我们：好用的 Agent 不是靠一句漂亮提示词撑起来，而是靠任务状态、记忆、工具、边界、预算和验证流程一起工作。

这篇文章会按 6 个问题讲清楚：发生了什么/为什么重要/会影响谁/社区怎么看/我怎么判断/团队明天能怎么做。

一、发生了什么：神 Prompt 开始失灵了

这次真正有意思的，不是“Claude 5 又发了什么新能力”。

如果只把它写成模型发布新闻，那就有点像老板让你做经营分析，你最后交了一张显卡参数表——不是没用，但明显没打到痛点。

研究稿里最关键的信号是：Claude 官方博客在 2026 年 7 月 25 日被 Hacker News 推到 125 points、74 comments，标题直接把“context engineering”放在台前。与此同时，last30days 抓到围绕 Claude 5 context engineering 的 Reddit 和 HN 讨论，总量接近 998 upvotes、236 comments，以及 HN 4 条故事合计 3201 points、2119 comments。

换句话说，这不是一个小圈子自嗨词，而是国际社区真的在讨论：Agent 时代，到底该怎么组织上下文。

更有戏剧性的是，社区另一边正在吐槽“万能提示词”玄学。有人把所谓 Claude Fable 5 的系统提示词压缩成 500-token Markdown engine，评论区马上有人问：“有没有量化测试？”还有人直接吐槽“make no mistakes 这种句子到底有什么用”。

这句话很扎心，但也很真实。

我前阵子帮朋友看一个内部客服 Agent，他的系统提示词长到像一份租房合同：禁止这个、必须那个、遇到情况 A 怎么办、遇到情况 B 怎么办。结果上线后最麻烦的不是模型不听话，而是没人知道哪条规则导致了哪次错误。改一次，像在拆炸弹，手一抖就炸出新问题。

这就是今天的核心变化：提示词不再是“咒语”，而开始变成系统设计的一部分。

二、为什么重要：上下文不是文字，是运行环境

很多人一听“上下文工程”，第一反应还是：是不是把 Prompt 写得更长、更细、更像论文？

不是。

如果提示词是一张任务说明书，上下文工程更像一个小型操作系统。它要决定：哪些信息可以进来，哪些必须挡在外面；哪些记忆需要长期保存，哪些只是一次性便签；哪些工具可以调用，哪些动作必须人工确认；长任务做到一半，怎么压缩历史而不丢关键状态。

这件事重要，是因为 Agent 不像普通聊天机器人。

普通聊天答错一句，最多让人皱眉；Agent 如果带着错误上下文去调用工具，可能会删错文件、发错消息、查错客户、走错审批。说得俗一点：聊天机器人胡说八道像同事开会跑题，Agent 胡说八道像实习生拿着管理员权限乱点鼠标，刺激程度完全不同。

Claude 5 的讨论之所以热，不是因为大家突然爱上了新名词，而是因为团队真的被这些问题折腾过：

对 36 到 45 岁的工程负责人、产品负责人、业务主管来说，这背后其实是 ROI 问题。

你买更强模型，当然能提升一点上限；但如果上下文管理混乱，团队很快会把省下来的钱花在排查事故、返工和安抚用户上。这个账不难算，难的是大家以前总把它算到“模型不稳定”头上。

三、影响分析：Agent 越能干，错误上下文越贵

为什么这个变化会在 Agent 时代被放大？

因为 Agent 的工作方式天然是多步的。

它先理解目标，再查资料，再调用工具，再生成中间结果，再根据反馈继续行动。每一步都会消耗上下文，也会产生新的上下文。前面塞错一点，后面就会像复印机复印十代身份证，越往后越糊，最后还一本正经地告诉你“我完成了”。

一个具体工作场景：销售团队用 Agent 做客户跟进。

如果上下文里混入了过期报价，它可能给客户生成错误方案；如果历史沟通没有摘要，它可能重复问客户已经回答过的问题；如果工具权限太大，它可能把草稿邮件直接发出去。最后业务同事的感受不是“模型能力真先进”，而是“这玩意儿怎么像刚入职三天还很自信”。

另一个场景：研发团队用 Agent 辅助改代码。

如果项目约束、测试规则、发布流程没有结构化进入上下文，它很容易只看局部文件就开始动手。看起来勤快，实际像装修师傅没看承重墙就抡锤。短期有产出，长期给团队留下看不见的技术债。

研究稿里提到几个 GitHub 同频案例，虽然今天不把单个仓库作为主角，但它们很能说明方向：

• pi-textbook 用 15 个真实 checkpoint 讲从零构建 Pi-style Agent；
• graph-engineering 把知识图谱流水线和任务图编排做成 Claude skill；
• andrej-karpathy-skills 把 Karpathy 关于大模型写软件的 field notes 变成 Claude Code guardrails。

这些项目共同指向一件事：大家正在把“怎么跟模型说话”，升级成“怎么把知识、流程和护栏固化下来”。

这里还有一个容易被忽略的成本项：上下文预算。

长上下文听起来很爽，像给你一个无限大背包。但背包越大，不代表你越会旅行。真正的问题是：你要带水、证件和充电宝，而不是把家里电饭煲也塞进去。

对企业来说，上下文预算就是钱、延迟和可控性。能不能把一小时会议压成 10 条可执行状态？能不能把历史客户记录变成 5 个关键字段？能不能在工具调用前只保留必要信息？这些听起来不如“新模型参数”性感，但更接近真实 ROI。

四、各方观点：官方讲规则，社区反玄学，中文用户在补系统课

从来源看，这次话题有三股力量。

第一股是官方。Claude 官方博客把 context engineering 写成新规则，说明它不再只是提示词技巧，而是新一代模型使用方式的一部分。再叠加 Claude Opus 5 相关 HN 讨论 1735 points、1258 comments，背景热度足够。

第二股是国际社区的反玄学情绪。

Reddit 那些吐槽表面上很嘴毒，背后其实是工程师本能：你说这句提示词有用，那测试在哪里？你说“make no mistakes”能减少错误，那指标是什么？你说压缩成 500-token 还保留能力，那对照组呢？

这不是抬杠。工程世界里，不能验证的优化，通常只能算许愿。

第三股是中文用户的需求侧背景。

研究稿里提到，中文社媒结构化抓取因为公共额度不足返回 0，但 B 站 fallback 仍然有强信号：智能体 搜索出现 95.2 万播放的“AI Agent 智能体搭建教程”，大模型 搜索出现 147.3 万播放的“从 LLM 到 Agent Skill，一期视频带你打通底层逻辑”。

这说明中文读者并不是只关心“谁家模型第一”。很多人其实已经意识到：要把 AI 真正放进工作流，光会聊天不够，还得会搭系统。

我身边一个做运营的朋友就很典型。他最开始问我：“有没有一个提示词，能让模型稳定写出我们品牌风格？”后来折腾两周，他的问题变成：“我们是不是应该先整理过往爆款、禁用词、审核规则和发布流程？”

你看，问题从一句话，变成了一套流程。

这就是上下文工程的价值：它把“灵感型调参”变成“组织型资产”。

五、我的判断：下一个分水岭，是可验证 Agent

我的判断很简单：未来一段时间，真正拉开差距的不是谁收藏了更多神 Prompt，而是谁能把上下文做成可验证、可复用、可治理的系统。

这句话听起来有点硬，我们拆开说。

第一，可验证。

每一条关键指令都应该能回答：它解决什么问题？有没有反例？改动后错误率、返工率、人工介入率有没有变化？如果团队说不清，只是因为“感觉更稳”，那就像厨师说“我加了一点灵魂”，好吃可以，复制就难了。

第二，可复用。

好的上下文不应该锁死在某个同事的聊天窗口里。客户画像、项目约束、工具权限、输出格式、验收标准，都应该变成团队资产。否则员工一换岗，Agent 也跟着失忆，像办公室那台永远没人会修的打印机。

第三，可治理。

Agent 越深入业务，越要回答边界问题：哪些工具能自动用？哪些数据不能进上下文？哪些输出必须留痕？哪些记忆过期要删除？这些不是“以后再说”的合规细节，而是能不能放心上线的前提。

所以我不太建议团队继续把主要精力放在“再找 20 条高级提示词”。

更值得做的是搭一个轻量上下文框架：

这 6 个问题，比“请你作为世界级专家”更土，但更管用。

六、值得关注的方向：AI 工程会越来越像组织设计

最后说一个更大的趋势。

过去我们谈 AI 工程，常常还停留在工具层：接哪个模型、用哪个框架、套哪个模板。接下来，它会越来越像组织设计。

为什么？

因为上下文工程本质上是在回答组织问题：谁知道什么，谁能做什么，谁来检查，什么信息该留下，什么信息该忘掉。

这和管理团队很像。一个新人入职，如果你只丢给他一句“好好干，别犯错”，那大概率会翻车；如果你给他目标、资料、权限、边界、检查清单和反馈机制，他才可能稳定产出。Agent 也是一样，它不是缺一句鸡血口号，它缺一套工作环境。

对团队来说，明天就可以做一个很小的动作：把正在使用的 3 个 AI 场景拿出来，逐个问下面 6 个问题。

1. 任务目标是否稳定，还是每次临场解释？
2. 上下文从哪里来，是人工粘贴，还是系统自动取数？
3. 哪些记忆可能污染判断，是否有过期机制？
4. 工具权限是否最小化，危险动作是否需要确认？
5. 长任务什么时候压缩，压缩后保留哪些状态？
6. 输出由什么检查，能不能量化通过率？

如果这 6 个问题答不上来，先别急着买更贵的模型。

那就像房子地基还没打平，就开始挑水晶吊灯。不是吊灯不好，是它救不了歪楼。

Claude 5 这波讨论真正提醒我们的，是 AI 工程正在从“会提问的人更强”，转向“会设计运行环境的团队更强”。

神 Prompt 当然还会有用，但它只会是系统的一部分，而不是系统本身。

项目地址：Claude 官方上下文工程文章^[1]

Stars：非 GitHub 单项目，无 Stars 数据 （截至 2026-07-26）

一句话总结：Claude 5 带火的不是新咒语，而是一个更现实的判断：Agent 想稳定创造 ROI，必须先把记忆、工具、边界和验证流程工程化。

你们团队现在的 Agent，更像“神 Prompt 驱动”，还是已经有上下文系统？评论区聊聊，我也想看看大家踩过哪些坑。

这里是「AI工程手记」。

我会持续更新 AI 工程、Agent 工作流、自动化实战和开源项目观察。

关注 AI 工程怎么真正跑起来。

引用链接