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

6.3 KiB

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:

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:

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:

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:

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.