AI Engineering Methods

System methods for Agent Harness and knowledge engineering

These are not generic software engineering notes. They are recurring practices for putting large models into real engineering systems: task modeling, context selection, tool boundaries, verification and repair, graph application engineering, knowledge engineering, and replay systems.

Tasks should be modeled, not merely answered

Sources: GraphPilot · Hovo · Guanlan

Real user requests often span multiple messages, attachments, execution state, logs, artifacts, and follow-up questions. Explicit task modeling lets the system know where it is, where it failed, and where it can resume.

GraphPilot models session, message, task, timeline, artifact, and snapshot.
Hovo models session, request, scenario run, node run, workpaper, and business log.
Guanlan links SQL plans, datasets, report outlines, and report fragments as evidence.

Context selection matters more than context piling

Sources: GraphPilot · Hovo · GraphRAG · relation-graph

More context is not always better. The system should choose relevant materials based on task type, target platform, attachments, workspace history, source tasks, example catalogs, and knowledge slices.

Reduce irrelevant material that occupies the model window.
Reduce hallucination around APIs, framework differences, and business rules.
Make the knowledge sources for each task explainable and reviewable.

Tool boundaries determine whether agents can enter real systems

Sources: GraphPilot · Hovo · Guanlan

Models should not directly hold arbitrary shell, filesystem, or database capability. A more stable pattern is to let the model propose plans or structured operations, while the system executes, validates, and records them.

File operations need path allowlists, sensitive file protection, and size limits.
Database queries need read-only constraints, SQL validation, and bounded repair.
Business tools need input/output schemas, permission control, and call logs.

Verification and repair should be part of the Harness

Sources: GraphPilot · Hovo · Guanlan

Agent output should not rely on looking plausible. Code generation, data analysis, and report generation all need deterministic checks and local repair paths.

GraphPilot includes static review, self-review, build repair, and snapshot build.
Guanlan validates SQL, JSON Schema, report structure, and HTML fragments on the server side.
Hovo uses runtime logs, business logs, workpapers, and node results as review material.

A graph application is an operation interface, not a chart

Sources: relation-graph · GraphPilot

Complex relationship data is not a static image. It needs layout, dragging, zooming, expansion, editing, events, minimap, detail panels, and business state to work together.

The data model must contain both graph structure and business objects.
Core component capabilities should be separated from framework adapters.
When AI generates graph apps, data contracts, platform differences, and interaction rules need to be part of the knowledge assets.

Knowledge engineering should preserve structure, not only embeddings

Sources: GraphRAG · relation-graph · GraphPilot

If documents, examples, and API references are only split into text chunks, much of their structure is lost. A stronger approach preserves document trees, entity relations, semantic vectors, and retrieval audit data together.

Document trees preserve hierarchy and context location.
Entity relations help the system expand and associate recall results.
Retrieval audit data makes answer evidence reviewable and improvable.

Replay and artifacts are the base for system improvement

Sources: GraphPilot · Hovo · Guanlan · GraphRAG · A-share research

Without records of inputs, outputs, errors, repairs, and artifacts, agent systems cannot learn from real tasks. Artifacts are not random attachments; they are material for later evaluation, diagnosis, and iteration.

Task replay can turn real problems into repeatable evaluation samples.
Logs and diagnosis locate model, tool, context, or data source problems.
Business results and workpapers let non-technical roles participate in review.

Make domain knowledge reusable and verifiable through versioned knowledge packs

Sources: GraphPilot · relation-graph · Hovo

The important part is not simply having runtime packs. API constraints, common errors, examples, counterexamples, and platform differences should become versioned assets that the platform injects by task type.

Domain knowledge moves out of one-off prompts and becomes a maintainable system asset.
Only matching knowledge packs are injected for each task.
Pack versions enter task snapshots so failures can be traced to a concrete knowledge version.

Avoid regenerating from scratch by using historical outputs as baselines

Sources: GraphPilot · Guanlan

Follow-up tasks should reference previous tasks, HTML, SQL, datasets, or artifact IDs instead of restating the whole requirement. The platform helps the model locate the modification scope.

Historical artifacts become addressable context rather than manual copy-paste material.
The platform stores artifact IDs, task IDs, and prior results for local continuation.
Modification requests are grounded in a clear baseline, reducing rework and unintended edits.

Turn model output into verifiable objects with schema contracts

Sources: Guanlan · Hovo · GraphRAG

The point is not merely asking for JSON. Model output must satisfy field, type, ID, SQL safety, and data binding rules before it enters the execution path.

Model output is structurally validated before execution.
The server checks safety boundaries, legal fields, and object references.
Validation errors become repair context instead of simply ending the task.

Use error classification and minimal context for local repair

Sources: GraphPilot · Guanlan · Hovo

After failure, the system should not blindly redo everything. SQL errors, build errors, rendering errors, and tool-call errors should enter different repair paths with the smallest useful context.

Different error types enter different repair flows.
Repair context contains only the failing fragment, error message, and necessary constraints.
The repaired result goes through deterministic validation again.

Make results traceable by storing execution evidence automatically

Sources: Guanlan · Hovo · GraphRAG

Evidence chains should be generated during execution, not manually prepared afterward. SQL, datasets, node runs, knowledge recall, tool calls, and artifact IDs should be bound to final output.

Trace data is produced during execution.
Final reports, answers, or workpapers can be traced back to data, tools, and knowledge sources.
The evidence chain supports audit, debugging, review, and later iteration.

Let each scenario define its business workpaper structure

Sources: Hovo · Guanlan

The platform should not force every app into one report shape. Scenario apps define their own workpaper templates, fields, nodes, and artifact structures, while the platform handles lifecycle and governance.

Scenario apps define business expression; the platform manages lifecycle and governance.
Different businesses can own different fields, nodes, templates, and output structures.
Workpapers are both output results and reusable business objects.

Use original and normalized questions for more stable retrieval

Sources: GraphRAG

User questions may be informal, abbreviated, or semantically jumpy. Searching with both the original and a normalized question, then merging results, improves recall stability.

Keep the original question so normalization does not lose intent.
Generate a normalized question to fill in terms, objects, and query expression.
Merge dual-path results before reranking and context assembly.

Add section paths and parent context to isolated knowledge fragments

Sources: GraphRAG

A vector hit may lack context. The platform should add title hierarchy, parent nodes, and section paths so the model knows where the fragment belongs.

Recall results include not only text but also document paths.
Parent sections provide definition scope, assumptions, and boundary context.
Answers based on structured context reduce fragment misinterpretation.

Merge low-information fragments by document structure

Sources: GraphRAG

Smaller chunks are not always better. Overly small fragments can lose meaning, so the system should merge low-information nodes based on the title tree and content density.

Use document structure to decide whether a fragment has independent meaning.
Merge low-density fragments into parents or adjacent structures.
Chunk granularity should serve answer quality, not just vector database ingestion.

Turn high-quality examples into retrievable product assets

Sources: relation-graph · GraphPilot

Examples are not just documentation accessories. They can be classified, retrieved, and injected into agents to constrain code style, API usage, and interaction patterns.

Examples are classified by scenario, capability, framework, and API.
Agents can receive the closest examples during generation.
High-quality examples serve learning, documentation, and AI generation at the same time.

Turn historical tasks into replay and evaluation samples

Sources: GraphPilot · Hovo · GraphRAG · A-share research

The platform can store task inputs, context, tool calls, artifacts, errors, and repair steps, then use them later for replay, model comparison, and system diagnosis.

Real tasks become repeatable evaluation samples.
Changes to models, prompts, knowledge packs, and tool strategies can be compared through replay.
Historical errors become inputs for the next round of system improvement.