Ai相关 - ldfd

此处主要讨论coding情境下的上下文。

首先最粗暴的就是换一个大上下文的模型。

分块处理，将超长输入分割成多个chunk，每次调用模型时只输入一个块及必要上下文前后文，有时还会对前后块生成内容进行合并或摘要。在代码场景则为采用 AST（抽象语法树）感知分块。

摘要，就是用llm对上下文进行总结，这种只适合文档这一类的。具体的code如果摘要应该会失真。可以用来作为索引，生成一个md指示哪些文件是干什么的。

RAG。通过向量数据库，进行检索。当然代码向量检索肯定是不准确的，所以可以：

增量编译/差分补丁。使用git diff，仅分析变更部分。当然这个肯定需要知道整个函数长啥样

最佳实践（Diff + Context）：

Harness其实就是限制agent的实现路径，不过工程实践百花齐放，所以众说纷坛，根本看不懂。

这里我们跟随万恶的Claude博客分析一波。

这个是最早的一篇文章，甚至是2025年的。文章主要讨论了，agent面对长期大任务的问题。总结如下

问题	初始化代理行为	编码代理行为
过早宣布胜利	建立结构化的 JSON 功能列表文件。	会话开始时读取列表，仅选择一个未完成的功能点。
环境混乱/进度不明	初始化 Git 仓库和进度记录文件。	读取 Git 日志和进度文件；结束后提交 Git 记录并更新进度。
功能标记草率	设定明确的功能验收标准。	必须通过自动化工具进行自验证，通过测试后方可标记“完成”。
启动应用困难	编写 `init.sh` 脚本用于启动开发服务器。	会话开始首先运行脚本。

简而言之就是给agent一个todo list，然后用git控制版本，明确通过测试验收，还要保证能够轻松跑起来（类似人类配置环境的痛苦）。(注意此时的需求拆解是人写的，下一篇文章提出用ai写，即planner)

拆解可以像传统软件工程一样拆解成feature story task，随着模型能力增强，拆解的颗粒度可以越来越粗。

本文虽然也是Harness但是解决的问题不同，主要是上下文焦虑（临近限制时降低质量），自我评价偏差（自恋写生成的内容）。但是自恋这一块主要是前端的问题，也就是现在的ai前端同质化的情况。

上下文部分：

自动压缩 (Compaction)： 像是在同一个大脑里不断梳理记忆，减掉细枝末节，但身份和连续性不变。它更简单、延迟低，但在旧模型上可能无法彻底消除“接近上限时的焦虑感”。

上下文重置 (Context Resets)： 像是“换班”。旧 Agent 把工作写成**交接文档（Handoff Artifact）**交给新 Agent，然后旧窗口彻底清空。这能提供最干净的逻辑起点，但增加了编排的复杂性和 Token 开销。

自我评价部分：

借鉴生成对抗网络 (GAN) 的思路，作者设计了一个双智能体结构：

生成者 (Generator)： 负责编写代码。
评估者 (Evaluator)： 使用 Playwright MCP 实际运行页面、进行交互和截图，并根据预设的客观标准（如：设计质量、原创性、工艺、功能性）进行无情的批判。
效果： 这种循环迫使模型跳出“AI 样板风”的舒适区。在实验中，模型甚至能从普通的网页设计飞跃到极具创意的 3D 空间交互体验。

针对更复杂的全栈任务（如开发一个复古游戏制作工具或数字音频工作站 DAW），系统演进为三个角色：