Files
agent/docs/08-next-work.md
T
2026-07-12 14:54:03 +08:00

168 lines
6.3 KiB
Markdown

# Next Work
last_reviewed: 2026-07-12
## P0: Build One Stateful Learning Path
Use Agent Memory as the first vertical slice, but do not reuse the failed 45-minute lecture format.
The unit of interaction should be a claim, not a paper. A minimal claim object needs:
```text
question
claim
supporting evidence
counterevidence
confidence
scope / failure boundary
prerequisites
related claims
user judgment
last reviewed / next review
```
The first path should contain a small number of consequential claims from the existing audit, for example:
- strong retrieval can dominate write complexity on static QA;
- current-value maintenance is distinct from retrieval;
- execution-state memory is different from historical recall;
- automatic experience promotion requires evidence and rollback;
- memory can have negative marginal value inside an Agent scaffold.
The interaction should progressively reveal:
```text
problem -> current hypothesis -> evidence -> conflicting evidence
-> user judgment -> application to a new design -> delayed recall
```
Persist the user's state. Merely rendering these sections is not enough.
### P0 Data Work
Define a versioned, inspectable local schema before adding a database. Suggested initial files:
```text
data/learning/claims.json
data/learning/user-model.json
data/learning/reviews.jsonl
```
Requirements:
- every claim links back to evidence-ledger entries;
- user notes and AI synthesis remain distinguishable;
- claim updates preserve history;
- confidence changes record a reason;
- review records are append-only;
- no generated summary can silently replace source evidence.
### P0 AI Roles
Use AI above the per-paper level:
- evidence auditor: check whether a claim is actually supported;
- contradiction finder: surface papers that challenge the current model;
- synthesis maintainer: update the claim network when evidence changes;
- research partner: help the user reason through an unfamiliar target;
- review generator: create recall/application prompts from validated claims.
Use Luna for cheap classification, Terra for retrieval briefs and bounded dialogue, and Sol only for explicit synthesis/critique. The user also has a company GPT-5.5 data-agent API with effectively unlimited tokens, but integration must wait until its endpoint, auth, rate behavior, and data policy are documented.
### P0 Validation
Do not judge success by page completion or time spent. Validate whether the user can:
1. explain five claims without paper names;
2. identify the evidence boundary of each claim;
3. diagnose a new Agent memory design;
4. predict when memory will hurt;
5. recover the model after 1, 3, and 7 days;
6. change a belief when presented with counterevidence.
## P1: Connect Research to the Frontend
The current Atlas/search/reader can remain, but it should feed the stateful path:
- selecting a topic opens its unresolved questions and claims, not only a paper list;
- selecting a paper shows which claims it supports or challenges;
- search results can be promoted into an evidence review queue;
- paper chat can create a candidate claim, never an automatically accepted fact;
- the primary desktop focus should shift to the active research/learning task;
- mobile should preserve the same conceptual flow with fewer simultaneous panes.
Avoid another navigation-heavy redesign before the data and learning loop exist.
## P1: Continue Collection Selectively
Current gaps:
- only 6 JD items, last checked 2026-07-08;
- only 9 industry items;
- 959 of 974 paper items are still queued;
- paper source approval and automated collection policy need an explicit user decision;
- the corpus is heavily biased toward May-July 2026 and broad arXiv query terms.
Next collection work should be question-driven:
- refresh Beijing DeepSeek/Tencent/ByteDance/Alibaba/Baidu roles and record changes;
- add official company material that explains memory, evaluation, coding agents, or computer use;
- deepen only papers that challenge or extend current claims;
- do not add another thousand papers without a processing and evidence plan.
After any item changes:
```bash
python3 tools/collection/build_index.py
python3 tools/check_project.py
```
## P2: Research Refresh Protocol
When refreshing the memory audit or starting another topic:
1. define exact date windows and approved sources;
2. save the broad candidate snapshot;
3. separate deterministic filters from model triage;
4. identify comparable benchmarks and controlled studies;
5. read experiments, ablations, costs, and limitations in full text;
6. update an evidence ledger before writing conclusions;
7. preserve negative results and failed hypotheses;
8. record the run under `experiments/` and update project status.
Do not compare raw scores across papers unless model, embedding, prompt, visible information, and budget are controlled.
## P2: Operations
Still missing:
- public-domain deployment documentation outside this repository;
- authentication/authorization for a public or multi-user site;
- automated backup for future personal learning state;
- CI that runs `tools/check_project.py` on push;
- tests for web API behavior and frontend flows.
The repository now has an enabled user-level systemd service managed through `web/manage.sh`. It restarts on failure and survives user sessions because linger is enabled on the current host, but it is not a complete production deployment: proxy/TLS/auth configuration remains external.
## Explicit Non-Goals
- Do not make the graph more decorative as the next milestone.
- Do not present 974 queued papers as knowledge already learned.
- Do not revive the 12-paper lecture as the primary path.
- Do not use per-paper summary/translation as the main AI value proposition.
- Do not let AI write durable memory solely because a statement repeats in traces.
- Do not hide model, embedding, context, or cost changes inside an architecture comparison.
## First Continuation Task
The best next task for another AI is:
1. read the memory findings and evidence ledger;
2. define the claim/user-state/review schemas;
3. compile 5-8 audited claims into a stateful local dataset;
4. implement one progressive learning/research view;
5. run it with the user and record what changes in their understanding;
6. keep or discard the interaction model based on that evidence.
That is the shortest path from the current corpus browser toward the actual goal.