編碼智能體工作階段中的想法該存放在哪裏?
Where do the ideas from your agent sessions go?
作者比較了編碼智能體工作階段中保存待辦想法的多種方式,認為任務與延伸思路需要不同的存放形式。她以 GitHub Issues 和 Projects 看板追蹤工作,智能體可在下一個工作階段讀取看板,但看板仍會因缺少定期整理而留下過期狀態。她將有狀態、負責人及完成日期的任務,與需要呈現分支關係的想法區分開來。
A long session with a coding agent produces more than code. A bug you noticed on the way. An idea for a feature. A "we should also..." that the agent agreed to. Then the session scrolls on, gets compacted or closed, and the idea is gone. "Later" never comes, because nothing remembers it.
I have lost enough of those to try several places for them. None is perfect, and I want to know what you use, so this is a comparison with a question at the end, not a recommendation.
Scrolling back
The default. It works until the context is compacted or the terminal closes, which with agents is a few hours at most. I count it here because most people I ask are still on it.
A notes file in the repo
A NOTES.md, a CLAUDE.md, or the agent's own memory. Good for facts: the one flag that makes the build work, the trap in the deploy script. Bad for tasks. A line in a file has no status, no due date, and nobody closes it. I tried a step further with ai-tree, a tree of ideas per session drawn in a local page, and asked the agent in CLAUDE.md to keep it updated. In long sessions it forgot. The version that works has a watcher outside the agent reading the session log, which tells you something about asking the agent to remember on its own.
The agent's built-in task list
Claude Code has one. I switched it on (CLAUDE_CODE_ENABLE_TODO_TOOLS=1), looked at where it keeps things (~/.claude/tasks/<session>/, one JSON per task, a new session sees the old list only with the same list id), and never went back. The list lives inside the agent. I don't look inside the agent for my plans, and nobody else can look there at all.
Jira, when it's company work
In a company the question is already answered. The process is described, the fields are agreed, and the only thing the agent needs from me is the rules of that culture, or a few example tickets to copy. Then it files tickets that look like everybody else's. It works, and there is nothing to discover in it, so it gets one paragraph.
GitHub Issues plus a Projects board
This is my exotic one, and it earned its own picture. For a project I build together with the agent, every "later" becomes an issue, and the issues sit on a GitHub Projects board with two lanes: owner:you for things only I can do (register an app, decide, publish) and owner:claude for code and docs. The agent is the board's secretary. It files the card, gives me the link, moves the status with gh project item-edit, and closing the issue means done. I only close. The setup, labels and gh commands included, is written up as a story your agent can reproduce: The Relay Board: my agent runs the GitHub kanban, I just close my cards.
Two things made me stay with it. The board is public, so a stranger found an issue about porting my MCP server to a new spec revision and left three detailed comments, including a correction against their own project. That has never happened to me in Jira. And the agent reads the board next session, through gh, so the "later" survives the session without me pasting it anywhere.
Now the honest part. Here is the marketing board for the same project, six weeks later, drawn from the live data today.
A card for an article that was published yesterday is still "In Progress". A closed issue sits in "waiting". Eight outreach cards are two weeks past their due date. Nine cards have not been touched in over a month. Nobody did anything wrong. The agent filed every card it was asked to file, and I closed what I remembered to close. The board just has no one whose job it is to look at it.
So the rule I have now: a board the agent writes to needs a routine the agent runs, every day, without me asking. It is an AI in the project manager role: not the one doing the work, the one keeping the board honest. Open the board. Say which cards are due or overdue. Close what this session already solved, because the session often solves a card nobody mentioned. Ask about anything untouched for three weeks: still wanted, or close it. I already run a short morning briefing from a headless agent on a schedule; the board check belongs in it, as a standalone cleaner that touches nothing without saying so. I have not built that part yet, which is why the picture looks the way it does.
A board you look at vs a board you work on
I also tried copying the same board into Miro as a mind map, a timeline, and an impact-versus-effort grid, because the agent can draw there through MCP and the views are nicer. The copies faithfully reproduced the stale statuses of the GitHub board. A whiteboard is a picture of the work. On GitHub the agent and I act on the same objects (gh issue close is the truth). On a whiteboard someone has to keep the picture in sync, and that someone is the same person who did not look at the board.
Two kinds of "later"
Ideas from a session come in two kinds, and I think they need different places. Tasks ("do this") need a status, an owner, and a closed-with-a-date. Issues, boards, Jira, and the built-in task list are built for them. Branches of thought ("I could go this way") need a map of what grew from what and what was set aside. ai-tree and mind maps are built for those. Most tools cover only the first kind, and I keep losing the second.
Your turn
- Where do your agent's "laters" go? Does the place survive the session, and can the agent read it next time?
- If you use Linear or Jira through MCP: does the board stay honest without you, or does it rot like mine?
- Has anyone given an agent a daily cleaning routine over a tracker? I would like to see to make mine better.
來源:DEV Community · dev.to


