How I work with Agents

📝 摘要 #

作者总结了他截至 2026 年 10 月使用编码 Agent 的 16 条实践：始终使用最新最强的模型；不再过度担忧 AI 生成代码带来的 slop；用「描述 What 而非 How」的方式下指令；把整个 SDLC 变成 Agent 可读、可操作的对象，并为 bug 报告、发邮件、健康检查、feature flag 等环节提供工具；用对照实验评估 AGENTS.md / skills 是否真的被 Agent 使用；不要人机来回试错，而让 Agent 自己造工具（生成 20 个变体 + 对比页面、提出 4 个假设逐一验证）；要求不可辩驳的证据（端到端演示、demo 视频、前后对比数字），并在 AGENTS.md 里写明「这不是证据」；拥抱异步，让 Agent 等你而不是你等 Agent；把定时 / 唤醒 / 心跳当作杀手级功能；不要手动管理 context，交给 compaction；每个线程只做一件事，而线程本身就是公司记忆；只审查爆炸半径大的代码。

核心概念： 把 Agent 当作需要完整可观测性与可验证证据的工程协作者，而不是需要人逐步指挥的补全工具；人的角色从「写代码、盯过程」转向「定义 What、提供工具、审查高爆炸半径变更」。

关键技术栈 / 关键要点：

1. 模型选择 — 用最新最强模型；便宜但更笨的模型会带来重试成本，反而更贵。
2. What not How — 给目标与验收标准（如「把字节码编译器和 VM 做到 2x 快」），不规定实现路径。
3. SDLC 可读性 — Agent 看不到的东西就会编造；让它读生产日志、部署、观察 rollout、发布、处理 bug、给客户发邮件。
4. Agent 造工具来迭代 — 让 Agent 生成变体与对比工具，而不是人机反复「试试这个、再试试那个」。
5. 不可辩驳的证据 — 端到端 walkthrough、demo 视频、before/after 数字；diff 和绿灯本身不算证据。
6. 异步与心跳 — 给更大的任务、批量处理；用 schedule / heartbeat 让 Agent 定时检查日志、上线后通知、每天 9 点巡检。
7. 上下文与审查 — 不手动管理 context；一个线程一个任务；只审查不到 5 个核心文件、数据库迁移等高爆炸半径变更。

关键结论 / 实践建议： 把工程重心从「与 Agent 来回对话」转向「为 Agent 构建可观测、可操作、可验证的 SDLC 环境」，并以证据而非 diff 作为完成标准。

... as of October 2026.

Use the latest and greatest models. Everything else is potentially a waste of time. If a model is wrong 10% of the time, you don't know which 10%, so you end up making multiple attempts. When do you really want to hire a generalist who's 50% cheaper but also randomly 20% dumber? Who's still using Opus 4.5? Exactly.

Stop worrying about accumulating slop. "It'll turn your codebase into an unmaintainable mess." Maybe that was true six months ago. Now? I'm not convinced it adds slop. And even if it does, I'm not convinced the result is unmaintainable.

Prompt the What, not the How. Describe What you want, now How you'd do it. You'll often get better results. "Make the bytecode compiler and VM AS FAST AS YOU CAN. Do not stop until it's 2x faster." "Here's how it should work in the end"

Make the whole SDLC legible to the agent. What stopped hallucinations? Tool calls. They let agents touch our reality. If the agent can't see something, it makes it up. So let it run what it builds end to end, let it read production logs, deploy, watch the rollout, cut the release, flip the flag, triage the bug report and email the customer. Anything you can see, the agent should see too.

Give it tools for the SDLC. We have custom plugins for bug reports, emailing users, "Is our system healthy?" and granting featuer flags.

Eval agentic knowledge. Knowledge piles up in the codebase: AGENTS.md files, skills, scripts, docs. But do agents actually use it? Spawn five blind agents, control vs. treatment, and find out. Agents are really, really good at running experiments.

Local dev feels yucky now. Each agent should be able to install and run whatever it needs to get job done. Easy in remote machines, yucky in local dev. Hard to not run into resource conflicts locally when you want agents testing stuff end to end.

Don't iterate with the agent. Let it build tools to iterate. Not "let's try this. ... ah no, let's try that." Instead: "Generate 20 variations and a little page that lets me combine and test them." Not only applies to solution space, but also problem space: "Give me 4 theories on why this is slow, then check all four."

Ask for irrefutable proof. Biggest game changer. Agents are really good at producing proof: end-to-end walkthroughs, demo videos, before/after numbers. You have to build up trust and an instinct for this. Put "this is not evidence" in your AGENTS.md.

Don't wait for your agents. Let them wait on you. If you worry about TTFT, you're probably doing something wrong. Lean into async. Give them bigger tasks, be more ambitous. Batch instead of back and forth.

Automation/schedules/wake-up/heartbeat are killer feature. Didn't realize it, but missed it dearly once it was off. Use it all the time. "Check the logs in 2hrs." "Let me know once this is live" "Check every day at 9am".

Stop manually managing context. Every thought you spend wondering about "is it using 300k or 380k tokens?" is wasted time. Compaction works incredibly well. Don't manage context by hand. One thread = one task. Some threads are 46 messages, some are 3,714.

Threads are your company memory. (In Amp) "Why did we do this?" The more team uses Amp the more knowledge multiplies. Threads are connected to git commits. Game changer. Avoids duplicate work.

Don't let agents write for humans. Except: debugging steps, inicident reports, some docs. Mechanical stuff where human on other end doesn't matter that much.

Review only code with high blast radius. There are <5 central files -- those I review. Database migrations, yes. Closure vs. class, a neater type, variable names, even duplication: I don't care anymore. Does it work? Do I understand it at the arrows-in-a-diagram level? Did the agent test it end to end? Can I change it in a month? If yes, might review code.