codex新版tui的context显示太傻了吧... 搞七捻三 [image] ？？？？？ 随手升了个级 之前好好的百分比 怎么换成了进度条了。。。从一眼看变成要预估了。。。 [image] 原来已经有人反馈了啊 [image] 好的 说的是根据用户反馈改的。。 然后被15个 是何意味 前几天刚提这个，那时候也有不少issue说这个问题。 今天更新到0.121.0 百分比居然回来了 不过… 这又是什么新活？ 8 个帖子 - 6 位参与者 阅读完整话题
虽然目前有一个 zenobi-us/pi-dcp ，但是已经两个月没更新了。 之前用opencode的时候感觉 Opencode-DCP/opencode-dynamic-context-pruning 很好用，可以不声不响地把context 保持在一个很低的水平。 换到pi-agent后，context动不动就飙升到40-50%。试了一下 mksglu/context-mode 和 MasuRii/pi-rtk-optimizer ，效果都不明显。用pi-agent的佬们，有没有什么好的管理办法？ 1 个帖子 - 1 位参与者 阅读完整话题
devnexus is an open-source cli that gives agents persistent shared memory across repos, sessions, and engineers. It maps out dependencies and relations at the function level, builds a code graph, and writes it into a shared Obsidian vault that every agent reads before writing code. Past decisions are also linked directly to the code they touched, so no one goes down the same dead end twice. Still building it out but I would love to hear any thoughts/feedback Comments URL: https://news.ycombinator.com/item?id=47812829 Points: 4 # Comments: 0
I've been presenting at local meetups about Context Engineering, RAG, Skills, etc.. I even have a vbrownbag coming up on LinkedIn about this topic so I figured I would make a basic example that uses bedrock so I can use it in my talks or vbrownbags. Hopefully it's useful. Comments URL: https://news.ycombinator.com/item?id=47808956 Points: 3 # Comments: 0
目前尝试组合以下几个工具： Augment Context Engine (ACE) MCP：语义检索减少全量文件投喂； JuliusBrussee/caveman Skills：减少冗余对话； rtk-ai/rtk CLI Proxy：过滤终端输出。 体感能省下至少 50% 的 Input Token，输出质量没有明显降低，想请教下还有哪些方案。 3 个帖子 - 3 位参与者 阅读完整话题
claude ▐▛███▜▌ Claude Code v2.1.112 ▝▜█████▛▘ Opus 4.7 (1M context) with xhigh effort · API Usage Billing ▘▘ ▝▝ C:\Users\dingy ❯ 你好 ⎿ 503 {“error”:{“code”:“model_not_found”,“message”:“No available channel for model claude-opus-4-7 under group auto (distributor) (request id: 202604170325133370552998268d9d6wLWX86kr)”,“type”:“new_api_error”}} Retrying in 12s · attempt 10/10 Nebulizing… (2m 53s) ⎿ Tip: Use /btw to ask a quick side question without interrupting Claude’s current work 这种情况是不是claude官方做了什么限制？ 现在国内中转站完全用不了了 3 个帖子 - 3 位参与者 阅读完整话题
Claude Opus 4.7 = Opus 4.6 + GPT 5.4 - (1m - Gemini 3.1 Pro Context) - Role Play ps:仅根据目前了解 [1] 作调侃,并没有实际上手体验测试过 1. opus 4.7 （high）cursor里面的，糖果问题和红绿色盲，锐评一下 - 开发调优 - LINUX DO 2. 来自官方System Card的Claude Opus 4.7牙膏倒吸实证 - 搞七捻三 - LINUX DO 3. 怎么感觉Opus 4.7 语气有点像GPT - 搞七捻三 - LINUX DO 4. claude4.7opus发布了,我生成了两张图可以概括4.7opus能力 - 开发调优 - LINUX DO ↩︎ 4 个帖子 - 3 位参与者 阅读完整话题
Article URL: https://ilha.build/ Comments URL: https://news.ycombinator.com/item?id=47791875 Points: 3 # Comments: 0
看了很多harness的文章和实现 我大致总结了一下， hook就是将agent的生命周期拆分成几个钩子（简单示例） before agent before model input before tool exec after tool exec after model output after agent 在不同的时期程序介入处理 然后将hook实现+工具+skill+agent上下文打包成插件 就能实现一个基本的harness系统的架子 包括记忆、状态、鲁棒性、观测性、权限约束、上下文压缩 都能以hook+工具+skill+agent上下文打包一个插件来实现 并且很容易通过移除、添加不同的类似插件来实现扩展性 6 个帖子 - 4 位参与者 阅读完整话题
Article URL: https://atticsecurity.com/en/blog/why-llms-hate-fake-data-token-proxy/ Comments URL: https://news.ycombinator.com/item?id=47778087 Points: 2 # Comments: 2
现在的compaction感觉不是很靠谱，无论是丢信息啊还是之类的。刚刚突然在想，之前经常因为一些原因一个session烂掉，这个时候我想续上这个session，我就会直接复制这个session的最后大约20k（我也不太清楚）的内容，然后作为prompt塞进下一个session就好了，然后对话就续上了 感觉比compaction便宜还快 不如直接做成每次满了，就去掉前80%然后就好了 虽然最好的方式显然是滑动窗口，但是由于缓存便宜，所以完全行不通。 评价是： context rot的根源是大模型太贵了（用缓存才稍微正常一点）（大模型厂商怎么这么坏，就知道节省计算资源 ）（虽然是缓存计算成本低是客观事实）（虽然缓存确实对用户的钱包更友好一点） 1 个帖子 - 1 位参与者 阅读完整话题
Article URL: https://github.com/manojmallick/sigmap Comments URL: https://news.ycombinator.com/item?id=47776309 Points: 3 # Comments: 6
I found that I often shy away from posts on Hacker News or sites like ScienceMagazine because I don’t understand every second word on the page. A simple dictionary extension doesn’t really help in these situations, because I’m not looking for the literal meaning of a word. Like one time I was reading a post about Rust compilers and the dictionary extension just failed hilariously.. “Rust” (the programming language, you fool!! not the thing that forms on iron when it oxidises -__-). What I actually need in these moments is context-aware explanations of concepts, not dictionary definitions. AI turns out to be pretty good at that. So I built a very simple tool for this — under ~300 lines of code — that has ended up saving me a ton of time. It works pretty simply: it takes the highlighted text, parses the HTML of the page for surrounding context, and sends both the page content + selection to an LLM provider of your choice (OpenAI, Gemini, or Claude). You can also reorder which provider you prefer. That’s basically it. I don't collect any data or anything. Here’s the GitHub link: https://github.com/oishika10/rhino I’m pretty sure this can be improved a lot, so I’d really appreciate feedback or ideas. This is the first project I’m sharing publicly like this. I enjoyed building this because made me realize how small, simple tools can still be surprisingly powerful and save me a ton of time in life. Comments URL: https://news.ycombinator.com/item?id=47776069 Points: 1 # Comments: 0
写这篇文章的起因很简单：我在 Twitter 上看到一个帖子，标题是"全网最完整AI科研终极指南"。点进去被浪费了人生的5分钟。 作者显然就是把几篇文章丢给ai，自动化的生产出一篇垃圾。流程图画得花里胡哨，工具列表也罗列得无比齐全，从文献检索到论文生成一条龙，看完让人觉得 AI 做科研这件事已经被彻底解决了。但凡真正用AI跑过一整套深度学习实验的人，都知道这篇东西有多离谱：它把科研最难、最脏、最痛苦的那部分，直接用漂亮的方框和箭头抹平了，就好像这个世界有一条通往成功的路，没有任何分叉和转折，AI就在那条路上一直往前走。 既然这种文章都有人点赞、有人收藏、有人转发，那我干脆也写一篇，把我自己踩过的坑、踩出来的经验，原原本本分享出来。 我是TOP10 的CS PhD 在读，发过 CVPR、ICCV、ICML、NeurIPS 等顶会，也担任过基本上所有主流顶会的审稿人。我有能力判断AI产出的东西到底有没有基本科研质量。 我用的主力模型是Claude Opus 4.6、GPT-5.4 xHigh，以及Gemini 3.1 Pro。我强烈不建议任何人拿低智能模型去做任何形式的科研探索，那纯粹是在浪费生命。 我目前订阅了Claude Max 20x、两个ChatGPT Pro、五个GPT Plus、Gemini家庭组Ultra，还有Super Grok。每个月Claude的额度基本能烧完，其中一大半都砸在了research上。这些订阅不是为了炫富，而是想证明：我真的把这套workflow从零搭起来、反复迭代过N次、真实跑通过，而不是看两篇教程就跑来分享。 Paper2Code、Sakana AI的The AI Scientist、Oh My Research、Hermes research skill，以及市面上能找到的各种“自动化科研框架”，我基本都clone下来对比过。结论很残酷：这些通用库对你真正发出一篇有价值的工作，几乎没有任何帮助。 注意，我不是说AI做科研没用，而是说“开箱即用的agent system”没用。你必须根据自己的领域、自己的方向，去定制一套真正属于自己的workflow。如果你连调试系统、控制上下文的能力都没有，指望一个现成的agent就能产出高质量科研成果，那基本是做梦。制造垃圾的话，其实连agent都不需要，一篇迭代过十几次的垃圾并不比GPT一键直出的垃圾高贵到哪里去。 至于什么“AI互相review”“多元模型投票”“多轮loop改论文”……这些听起来很高级、拍脑袋想出来的“科研skill”，在我看来大多是伪需求。你自己丢给Claude两个小时就能迭代出三版，比clone那些别人的skill高效得多。 但这篇文章也不是什么"AI 科研终极指南"，我没有能力写出任何形式的指南，除了深度学习我什么都不会，因此所有经验完全针对深度学习的科研工作流。其实深度学习我也不怎么会，这只是我个人在使用过程中的一些经验和教训，写出来希望能对你有帮助，哪怕只有一点点。 最后，在我不断迭代这套系统，写这篇文章的过程中，有一个认知越来越清晰： Context Is All You Need. 被污染的上下文会崩溃式地影响模型的能力。AI 一直修不好一个 bug，不一定是它没有这个能力，而是它的上下文已经被彻底带偏了。后面这篇文章里你会看到的所有设计、所有踩坑、所有我最终选择的方案，背后其实都只在做一件事：管住每一个 session 的上下文。 什么叫 AI 做科研 在开始聊具体流程之前，我必须先把一件事讲清楚：我所说的“AI 做科研”，到底指的是什么。 如今网上大量所谓的“AI 科研教程”，本质上只是在教你如何让 AI 生成一篇“看起来像论文”的东西。流程跑通，PDF 输出，排版精美，再让几个 agent 互相 review 一番，表面上无可挑剔。但那根本不是科研。 我认为，AI 真正参与科研，至少要守住以下底线： 整个过程不允许任何形式的造假。所有结论必须有明确出处；提出的 idea 与最终实现的 method 能够完全一一对应；实验的每一个结果，都是由真实代码训练得出的直接产物，任何人按照论文中的方法描述，都能复现代码、跑出一致的结果。 做不到这些，你用 AI 产出的就不是科研成果，而是学术垃圾。而且是带着 AI 高精滤镜、看起来更精致、但污染性更强的垃圾。 我把这一点放在最前面，正是因为后面你将看到的整个 workflow 设计，核心目的从来都不是“让 AI 写得更好看”，而是在严格确保：它提出的 idea 是真正被验证过的，实验是真正跑出来的，论文是真正可复现的。 这件事比大多数人想象的要难得多。但我认为它值得去做。因为它指向一个更长远的愿景：未来显卡资源的分配，应该分成三个方面：一部分用于训练更强大的基础模型，一部分用于日常 inference，还有一部分，应该交给每一个具体领域，让 AI 去探索那个领域的智力巅峰，不断推动学科向前。 而这个愿景能够成立的唯一前提是：AI 做出的科研，必须是真实的。 如果连结果的真实性都无法保证，那整条路从根子上就走不通。 流程概览 我全程使用多个模型协作。Claude、GPT、Gemini 各有明显优势，让它们交叉 review，其实就是一种形式的 ensemble。Ensemble 基本在任何场景下都能无痛提点。尤其是这几家模型是完全不同知识不同方式分别训出来的，知识覆盖范围、思考模式以及幻觉倾向也不尽相同，利用他们各自强大的地方以及交叉review在整个workflow非常重要。具体模型之间怎么调用、怎么交互，后面单独一个section讲。 一篇深度学习论文从零到投稿，流程大概是这样：文献调研，确定 baseline，复现 baseline，提出 idea，实现 idea，跑实验，分析结果，写论文。 这个流程不是一条直线走到底的。从"提出 idea"到"分析结果"这几步是循环的，idea 实现了发现不 work，跳回去重新想；结果有苗头但方法有问题，跳回去重新改。一篇论文定稿之前，这个循环往往会重复多轮。甚至，这些idea本身也不重要，重要的是在这个idea实验中的探索，以及拿到结果的分析，这些才是真正有价值的能帮到你的东西。一个idea直接拿到一个好的实验结果并不是最好的科研，这个idea也不属于你，真正经过探索拿到的结果才输于你。(From Saining Xie) 文献调研 文献调研这件事，只要接了正确的工具，Agent一定是比人强的，因为他的窗口知识量以及阅读速度比人强大太多了，它能在很短的时间里扫过大量论文，覆盖面远超你自己一篇一篇翻。但怎么让它搜到真正相关的东西，还是值得展开讨论一下。 我最早试了好几条路线。第一个想法是把能接的 MCP 全接上，arXiv、Hugging Face、Web Search，认为知识源越多覆盖面应该越大。但事实上基本很难搜到有价值的相关文章，我自己找到的相关论文都比这种方式找到的好。第二个想法是接 Zotero，因为 Zotero 里存的是我自己读过的论文，想让它把这些当作第一信息源，优先从我已有的知识库里找。Zotero 那条路回头想想就是个蠢主意，你自己读过的论文首先基数就在那里摆着，完全不足以充当idea来源，此外他们没有任何理由应该拥有更高的权重，该搜到什么不该搜到什么，应该由研究问题本身决定，而不是由你的阅读历史决定。 后来我把文献调研单独交给了一个 scout agent，底层用 Gemini CLI。原因很简单，Gemini 的搜索能力是目前所有模型里最强的。在交付搜索任务的时候，不需要你自己去拆关键词，Claude 在分派任务时天然就会把需求转化成结构化的描述交给 Gemini，Gemini 也会很自然的把结构化的需求拆解成多角度的搜索。这个是我在他们交互的过程中thinking的过程中看到的。另外我在搜索流程里加了一个约束：让 Gemini 重点关注中了顶会以及附带有开源代码的工作。因为后续不管是 review idea 还是选 baseline，论文的收录会议级别和有没有代码都是值得作为一个因子来调整我们的判断。 论文搜索到以后怎么进入模型的上下文也是值得展开讨论的。不管是 Claude 还是 GPT，你把一篇 PDF 丢进去，很多时候它不会真的从头读到尾。它会略读来回答你的问题，只有当你追问、而它发现自己答不上来的时候，才会回去再读一遍。而且一篇论文动辄三四十页，全塞进上下文窗口，不光浪费 token，还会稀释真正重要的信息。上下文里无关内容越多，模型注意力越分散。 所以我目前的做法是：如果能拿到 LaTeX 源文件或者 Markdown，就直接喂原文，不走 PDF。arXiv 上大部分论文都能拿到源文件，这条路是通的。Markdown 的好处是可以按需读，需要摘要就喂摘要，需要方法就喂方法那一章，不用一次性把整篇论文塞进去。在调研阶段，其实只需要读摘要和 introduction 就够了，你只是在判断这篇论文跟你的方向有没有关系，不需要在这个阶段就去看实验细节。 最后想强调一点，很多人觉得文献调研不重要，让 AI 自己想 idea 就好了。这恰恰是最大的误区。文献调研的本质是在给大模型构建一个领域专家级别的上下文。你拥有一个深耕某个方向的专家上下文，还是一个什么都知道一点但什么都不深的通用上下文，想出来的 idea 质量差距是巨大的。巧妇难为无米之炊，如果调研阶段搜到的论文就是一堆不相关的东西，那基于这些东西想出来的 idea，看着头头是道，但经不起任何推敲。 确定 Baseline Paper2Code 尝试过在没有 baseline 的情况下直接从论文生成代码，效果自然很不理想。这也符合真实的科研现状，极少数科研是从零开始写一套全新的代码，绝大部分都是基于某个 baseline 展开的。因此在开始讨论idea之前，一定要先确定好我们要做的setting和baseline。 复现 Baseline 复现 baseline 是整个 workflow 里最容易被低估的一步。 很多人以为复现只是为了"验证别人论文"，其实不是。复现的真正价值，是为你后续所有实验建立一个可靠的锚点，你的 idea 到底有没有提升，必须放在同一个框架下才能看得清清楚楚。 我最开始觉得有开源代码复现应该是一件不太困难的事，但是实际真正去做会发现他成功率并不高，很多时候即使成功也不是按照你期望的方式成功。 出错的方式包括但不限于：pip 装到一半报错，进程直接卡死，主线程不轮询一直等待。另外 Claude 有一个让人崩溃的操作，调用 bash 等各种工具都要调 sleep 等，一个几秒钟就能解决的错误，硬生生耗掉半小时。数据集下载也是一样，第一秒可能就因为网络波动挂了，但模型根本不知道，继续在那儿假装一切正常。另外我有好几台服务器，很多常用数据集其实早就下好了，路径也清清楚楚写在文档里，可 AI 压根不会主动去读那个文件，每次都从零开始重新下载，即使我明确写了数据集GPU使用文档并且放在CLAUDE.md的索引路径要求下载数据集/环境等之前必须读。 后来我尝试加监控：要求每一步必须实时反馈进度，卡住必须立刻报警，下完必须做指纹校验确认版本正确。但即使这样，在国内服务器、代理、网络不稳定的加持下，至今依然没有一次能做到完全稳健。他只会背着你偷偷继续 sleep 然后等你问他为什么没有根据 instruction 的时候和你说抱歉。 还有两个容易被忽略的点。第一，复现这种任务不要在主线程里跑。在主线程跑一方面会把安装报错、下载日志这些东西全部灌进上下文，污染后续的对话质量；另一方面你会被卡在前台干等，明明可以并行处理的事情变成了串行阻塞。交给 sub-agent 或者 exec 去做，主线程只负责收结果。第二，远程服务器上跑任何东西，一定要用 tmux，不要裸 SSH。SSH 断一次连接，整个进程就没了，之前所有的等待全部白费。 最终我得出的最现实结论是：最稳、最省心的做法，还是你自己先把环境搭好、数据下好，或者是 human in the loop 地看着它正确做完，再开一个新的 session 把干净的路径直接甩给模型。避免这种无休止的上下文污染和隐形时间黑洞。 提出 Idea 有了 baseline 和足够的文献积累以后，下一步是提出 idea。 我最早的做法是直接让 Claude 基于调研结果去想 idea。但是显然以Claude的智力很难提出有novelty的idea，此外它一个人既搜又想又评，上下文里混着调研笔记、论文摘要、它自己之前被否掉的想法，越到后面想出来的东西越飘，而且它会不自觉地往自己之前的思路上靠，跳不出去。在实现的过程中也会由于各种 idea 的混淆出现各种幻觉。 后来我改成让 Gemini 来做发散，因为这几个大模型的使用过程中比较明显的体感是，Claude 是几家模型中智力最低的，而 Gemini 虽然幻觉严重，但是我个人使用中经常能发现他提出一些让我有点吃惊的开脑洞的 idea，而且他的搜索能力和知识量应该是大于其他两家模型的，因此我考虑让他来广泛的提出 idea。Gemini 拿到的上下文只有文献调研的结果和 baseline 信息，它不知道之前有过什么讨论、什么想法被否过，所以能从一个干净的起点去想。一次生成大概 10 个 idea，每个 idea 带一段简要描述。 10 个 idea 出来以后，交给 Codex 做独立 review。因为 review 这件事需要的是严格的智力判断，Codex 在上下文确定的情况下给出判断是比较令人放心的。而且关键在于上下文隔离：每一个 idea 是单独评估的，Codex 拿到的上下文只有 follow 的那篇 baseline paper 加上当前这一个 idea 的描述，它看不到其他 9 个 idea，也看不到 Gemini 生成时的讨论过程。这样至少能保证评审过程是公平的，不会因为看到了别的 idea 而产生偏好。 review 的维度包括：novelty 够不够、技术上是否可行、跟 baseline 的兼容性怎么样、实现复杂度是否可控、以及预期能带来多大的提升。每个 idea 评审完以后会生成一个 idea card，包含各维度的评分和 Codex 的判断理由，同时给出一个明确的判定：go、revise 还是 kill。最后根据 ranking 选出得分最高的。 选出来以后，交给 Claude 拍板。Claude 作为主 architect，不是直接选了就走，还要回头看 Codex 的意见，如果 Codex 给的是 revise，Claude 需要判断是否采纳修改建议，把 idea 调整到位再继续推进。 确定以后，这个 idea 再交给 Gemini 做一次针对性的文献调研，专门搜这个方向上有没有已经做过的工作、有没有可以打磨润色的空间。通过这一轮验证的 idea，才正式进入实现阶段。 这个过程我试过很多策略，包括让 Gemini review、让 Claude 和 Codex 互相 review。最后放弃了所有"互相 review"的方案。原因很简单：只要让两个模型互相审，它们永远能告诉你"还能怎么改进"、“还可以从哪个角度优化”。这个过程没有终局。一定要有一个角色来做最终决定，而不是让它们无休止地互相照应。 而且这样的流程下，最终选出来的 idea，一定是三个模型共同认可当前上下文中综合情况更适合的 idea。 但在真正进入实现之前，还有一件必须做的事：写 research contract。 在动手写任何代码之前，先把所有预期写清楚：hypothesis 是什么，什么结果算成功，什么结果算失败，每个 ablation 预期会看到什么。失败信号要独立写，不是"没达到成功"的反面。 为什么要这么较真？因为如果你不在实验之前把这些确定，模型一定会在结果出来以后帮你合理化。跑出来的数差了一点，它会告诉你"虽然主指标没达标，但从另一个角度看这个结果其实揭示了一些有趣的现象"。做科研最忌讳的就是先看到结果再编故事。 contract 写好以后，后面所有角色都以它为唯一的尺子。写代码的要严格对照里面的超参、metric、数据 split 来实现，有偏差不能自己决定，必须回来问。评审结果的时候先读 contract 再看结果，逐条判定每个信号是达标还是没达标。写论文的时候，每一条 claim 必须能对应回 contract 里的某个信号和对应的实验数据。 而且 contract 一旦写好，实验开始以后不能改。如果确实需要修正，产出一个 v2，写清楚改了什么、为什么改。不允许事后调整 success signal 去配合结果。 未完待续… 1 个帖子 - 1 位参与者 阅读完整话题
底部那一行就是它加的。三个数字分别是： Context —— 当前会话用掉的上下文百分比。我一般看到 70% 就准备 /compact 了。 Usage —— 当前 5 小时窗口的额度用了多少，后面跟着距离重置还有多久（图里是 resets in 4h 9m ）。 Weekly —— 每周配额用了多少，同样带重置倒计时。 安装 在 Claude Code 会话里依次跑下面这几条。 添加 marketplace： /plugin marketplace add jarrodwatts/claude-hud 安装插件： /plugin install claude-hud 重新加载插件： /reload-plugins 配置 statusline： /claude-hud:setup 最后那条 /claude-hud:setup 会引导你把它配成默认 statusline。配完直接生效，不用重启。 Linux 用户在 /plugin install 之前最好先去看一下仓库 README，README 里有专门的说明。 如果你之前装过别的 statusline，可以先 /statusline 看一下当前是什么，再决定要不要换。 1 个帖子 - 1 位参与者 阅读完整话题
codex默认不显示上下文窗口 解决了 通过 /statusline -> context-usage 显示上了 1 个帖子 - 1 位参与者 阅读完整话题
I'm a sophomore CS student and built this as a side project to solve a problem I kept running into — jumping into an unfamiliar codebase with no idea where to start. It's a static analysis engine that: - Walks the repo in two passes (no unnecessary file reads) - Builds an import graph across 9 languages to rank files by importance - Assembles a token-budgeted context map in under 10 seconds - Works fully offline, no API key needed I've tested it on Next.js and gemini-cli. It's not perfect — pattern detection is keyword-based not structural, and monorepo support is limited. Happy to discuss the tradeoffs. Would genuinely love feedback on the engineering approach or anything that seems wrong/naive. Install:pip install context-engine-cli Comments URL: https://news.ycombinator.com/item?id=47771847 Points: 1 # Comments: 0
Article URL: https://github.com/hipvlady/agent-coherence Comments URL: https://news.ycombinator.com/item?id=47769407 Points: 1 # Comments: 0
Article URL: https://github.com/AxmeAI/axme-code/ Comments URL: https://news.ycombinator.com/item?id=47768862 Points: 2 # Comments: 1
之前做过一些AI应用的项目。踩过一些坑。最近整理了一些想法。贴出来跟大家交流一下。 过去几年，AI 应用工程的关注重点发生了一次非常清晰的迁移。早期开发者最关心的是，怎样写 prompt，才能让模型更稳定地理解指令、输出正确格式、减少跑题和幻觉。随后，随着长上下文、检索增强、工具调用和多轮状态管理逐渐成熟，问题转向了另一个方向：怎样为模型提供它在当前任务中真正需要的信息。再往前一步，当模型开始具备跨步骤执行复杂任务的能力，一个更深层的挑战浮现出来：即使模型已经理解任务，也拿到了足够的信息，怎样才能让它持续、可靠、可验证地把工作做完。 如果把这三个阶段放在一起看，就会发现它们并不是零散技巧的更替，而是 AI 应用工程的三层递进问题。第一层是 Prompt Engineering，解决的是如何表达意图；第二层是 Context Engineering，解决的是如何供给信息；第三层是 Harness Engineering，解决的是如何约束行为、验证结果并维持系统可靠性。它们共同构成了 AI Agent 从“能回答”走向“能工作”的一条演化路径。 Prompt关心的是接口，Context关心的是认知环境，Harness关心的是系统约束。理解这三层之间的关系，不仅能帮助我们解释行业讨论为何会从“提示词”转向“上下文”，再进一步转向“agent harness”，也能帮助团队在实践中更准确地判断：一个问题究竟应该在 prompt 层解决，在 context 层解决，还是必须上升到 harness 层解决。 Prompt Engineering 是最早出现、也最容易被大家感知的一层。原因很简单：在大模型开放 API 的早期，开发者最直接、往往也是唯一能控制的变量，就是输入给模型的那段文本。无论是最初的文本补全接口，还是后来的对话式界面，开发者首先面对的问题都是“怎么说，模型才更容易照着做”。因此，Prompt Engineering 的兴起并不神秘，它几乎是由交互形态本身决定的。模型能力尚不稳定时，表达方式自然成为第一控制杠杆。 Prompt 的作用，就是在人类意图与模型生成行为之间建立一个尽可能清晰、低歧义、可重复的接口。角色设定、示例提供、格式约束、分步指令，这些常见技术本质上都在做同一件事：让模型更准确地映射人的意图。但 Prompt Engineering 的边界也始终存在。它擅长解决的是“怎么表达”带来的偏差，却无法凭空补齐模型没有看到的信息，更无法独立解决跨轮次记忆、多工具协作、长任务验证和系统级恢复这些问题。当任务复杂度提升到一定程度，仅靠 prompt 写得更好，往往已经不够。 这正是 Context Engineering 兴起的背景。随着模型的上下文窗口扩大、工具调用能力增强、RAG 和各类记忆机制逐渐成熟，开发者开始越来越明显地感受到：很多失败并不是因为 prompt 写得不够好，而是因为模型没有在当下看到正确的信息。它可能不知道最新政策，不了解企业内部知识，不记得前几轮对话已经确认的决定，也可能虽然拿到了信息，却因为注入方式混乱而无法有效使用。到了这个阶段，问题的重心就从“如何提问”转向了“模型该看到什么”。 Context Engineering 的核心，不是简单地往上下文里塞更多内容，而是系统性地设计模型的认知环境。检索哪些材料、保留哪些历史、怎样压缩长文档、如何组织工具描述、哪些状态需要长期持久化、哪些信息应该在当前轮动态注入，这些都属于 Context Engineering 的范畴。它解决的是信息供给问题：在上下文窗口有限的前提下，如何在正确的时刻把正确的信息放进模型可见范围内。 这一层之所以重要，是因为大模型的很多“不会”，本质上不是能力缺失，而是信息缺席。模型在很多任务中并非不具备推理能力，而是推理所依赖的事实、状态和材料没有被正确供给。随着 AI 应用从聊天问答走向文档助手、代码代理、企业知识系统和工具增强型 agent，Context Engineering 逐渐从辅助环节变成主导环节，也就不难理解了。 但即便如此，一个拿到了正确信息的agent，仍可能在长任务中偏离目标，可能在没有验证结果的情况下过早宣布完成，可能持续复制代码库中的坏模式，可能在多次操作中悄悄积累错误，最终把本来局部可控的问题放大成系统性风险。到了这里，问题已经不再是信息供给，而是行为约束和系统可靠性。 Harness Engineering 之所以成为新的焦点，正是因为 agent 的失败模式已经超出了 prompt 和 context 两层能够单独解决的范围。Harness 所指向的，不是更多提示词，也不是更大的上下文，而是一整套包裹模型工作的外部系统：项目规则、状态文件、架构约束、自动化测试、静态检查、任务分解、反馈回路、回滚机制、子智能体编排，以及让错误能被发现、被反馈、被修正的全部工程设施。 如果说 Prompt 是告诉模型你要什么，Context 是让模型看到完成任务所需的信息，那么 Harness 做的就是让模型在真实系统里以可接受的方式把事情做成。它不是替代前两者，而是在前两者之上增加了一层对行为的调控。这个变化之所以关键，是因为一旦模型开始长时间自主工作，“回答对一个问题”就不再是核心标准，“能否持续在边界内完成一项任务”才是。 这也是为什么越来越多关于 agent 的高价值讨论，不再把注意力集中在单次输出质量，而是开始关注智能体的工作环境。没有测试的 agent 会自信地交付未验证结果，没有状态管理的 agent 会在跨会话中失忆，没有结构约束的 agent 会在代码库里不断扩散局部最优，没有反馈回路的 agent 即使犯了同一种错也会反复重演。换句话说，agent 的问题越来越像软件工程问题，而不再只是模型调用问题。 1 个帖子 - 1 位参与者 阅读完整话题