就在昨天早上，我正在写一篇关于维护 LLM 上下文窗口最佳实践的会议演讲，内容相当详细。它包含了以下两篇博文中当时的最佳实践。
然而，如果您使用Amp并参与了抢先体验，那么那次演讲的某些部分（仅仅 4 小时后）就变得多余了。这有点像是自己开发，但不必在那么低的抽象层次上工作也挺好。在更高的抽象层次上工作真的很棒。在下面的视频流中，您将看到子代理的原型。是的，它是真实的。它就在这里。
你无需将所有东西都分配到主上下文窗口，然后使其溢出，而是创建一个子代理，它拥有一个全新的上下文窗口，用于执行实际操作，例如构建、测试或任何你能想到的操作。在执行这些操作时，主线程会暂停并挂起，等待竞争的到来。
它有点像异步、等待状态机或 LLM 的未来。
昨晚真是睡不着。说实话，我一夜没睡，完全被它迷住了。之前它一直无限循环，会把主上下文窗口炸掉（这会导致代码库最终处于不完整状态），让我不得不跳回去处理其他事情，并提示我尝试修复它。现在，主线程，也就是上下文窗口，几乎不会增加，而且每次循环都能完成。
谢谢你， Thorsten ，让我的梦想成真。现在我又有了另一个梦想，但自从我加入Amp团队以来，我想实现梦想的责任就直接落在了我身上。我有责任完成它。
在整个行业中，软件工程师不断地将时间花在低商业价值的任务上。有些公司甚至称之为“KTLO”，即“Keep the Lights On”（保持灯火通明）。然而，如果忽视这些任务，就会给业务带来重大风险。然而，由于产品更重要，这些任务往往无法完成。因此，这始终是一个风险与回报的权衡。
所以这就是我们的宣传。所有这些任务很快就会实现自动化。现在我们已经通过子代理实现了上下文管理的自动化，下一步就是提供一些原语，以便自动化和移除 KTLO 类，或者用 Mr.10 喜欢用 Factorio 的术语来说——我们需要高质量的模块。
从票务到生产的路径
坦白说，行业和基础模型尚未实现完全自动化软件开发，无需工程师介入/介入。目前任何兜售这种梦想的供应商都只是在兜售些胡扯的魔豆，但人工智能发展迅速，或许再过几个月，我的问题就能迎刃而解了。
别误会——我们离目标很近了。Cursed（上图）的持续演进，一种完全由振动编码且无需动手的全新编程语言，向我证明了，假以时日，这一切终将实现。要知道，编译器可不是 Vercel v0 网站。不，它是严肃的东西。它不是玩具。编译器具有象征意义和实质内容。
构建该编译器是我今年所做的最好的个人开发之一。
- 它教会了我很多有关管理上下文窗口的知识。
- 它教会了我减少对人工智能代理的控制，并解放我的双手。
- 它教会了我每个法学硕士中的潜在行为以及如何利用潜在空间来实现新的成果或元层次的洞察力。
你知道，我们行业正在发生的变革目前还没有现成的指南。我努力在这个网站上记录我所有的观察。然而，只有通过认真、有意识的实践和实验，这些新兴行为才能显现出来，并转化为可以传授的模式。
但它从小事做起
在 GitHub 上的私有 Amp 代码库中，有一张美人鱼图。这张美人鱼图清晰地展示了我们 GitHub Actions 工作流程是如何将Amp发布给您的。它旨在帮助我们的员工更轻松地加入项目。
它是由以下提示生成的：
# Prompt to Regenerate GitHub Actions Mermaid Diagram ## Objective Create a comprehensive mermaid diagram for the README.md that visualizes all GitHub Actions workflows in the `.github/workflows/` directory and their relationships. ## Requirements 1. **Analyze all workflow files** in `.github/workflows/`: - `ci.yml` - Main CI workflow - `release-cli.yml` - CLI release automation - `release-vscode.yml` - VS Code extension release - `scip-typescript.yml` - Code intelligence analysis - `semgrep.yml` - Security scanning - `slack-notify.yml` - Global notification system - Any other workflow files present 2. **Show workflow triggers clearly**: - Push/PR events - Scheduled releases - Main branch specific events - TypeScript file changes 3. **Include complete workflow flows**: - CI: Build & Test → TypeScript Check → Linting → Test Suite - Server Build: Docker Build → Goss Tests → Push to Registry → MSP Deploy - CLI Release: Version Generation → Build & Test → NPM Publish - VS Code Release: Version Generation → Build & Package → VS Code Marketplace → Open VSX Registry - SCIP Analysis: Code Intelligence Upload → Multiple Sourcegraph instances - Semgrep: Security Scan → Custom Rules → Results Processing 4. **Slack notifications must be specific**: - `alerts-amp-build-main` channel for general main branch workflow success/failure notifications - `soul-of-a-new-machine` channel for CLI and VS Code release failure notifications - All Slack notification nodes should be styled in yellow (`#ffeb3b`) 5. **Color coding for workflow types**: - CI Workflow: Light blue (`#e1f5fe`) - Server Image Build: Light purple (`#f3e5f5`) - CLI Release: Light green (`#e8f5e8`) - VS Code Release: Light orange (`#fff3e0`) - SCIP Analysis: Light pink (`#fce4ec`) - Semgrep SAST: Light red (`#ffebee`) - All Slack notifications: Yellow (`#ffeb3b`) 6. **Global notification system**: - Show that `slack-notify.yml` monitors ALL workflows on main branch - Connect all main branch workflows to the central `alerts-amp-build-main` notification ## Task Output Create mermaid `graph TD` diagram which is comprehensive yet readable, showing the complete automation pipeline from code changes to deployments and notifications. ## Task 1. Read the README.md 2. Update the README.md with the mermaid `graph TD` diagram
太棒了，现在我们得到了一个生成美人鱼图的提示，但现在我们也遇到了 KTLO 问题。当其中一个 GitHub Actions 工作流程更新，或者我们引入新内容时会发生什么？嗯，错误的文档比没有文档更糟糕。
通过观察潜在空间，我注意到这些提示符和 Markdown 是一种奇怪的伪 DSL。它们几乎就像 Shell 脚本。如果你读过我的标准库博客文章，你现在就知道你可以将这些 DSL 链接在一起以实现所需的结果。
如果采取正确的方法，我认为修复企业版 KTLO 的模式也将与企业代码迁移的模式相同。例如，从 Java 的一个版本迁移到下一个版本，升级 Spring，或者将 .NET 4.8 迁移到较新版本的 .NET Core（即 .NET 8）。
是时候建设了。是时候让未来变得美好了。