11.1 What makes a system an agent
An AI agent is a system that selects and executes actions toward a task using observations, internal state, and available tools. Autonomy varies: some systems follow a fixed workflow with a model at one step, while others choose among tools and revise plans over several steps. A knowledge graph can provide structured state, memory, constraints, and evidence for either design. The presence of a graph does not by itself make a system autonomous, and autonomy does not imply that every action should be delegated to a model.
ReAct explores interleaving reasoning and acting in language model based systems [40]. For knowledge graph applications, the relevant architectural idea is that a system can inspect information, choose another action, and revise its approach based on the result. The user does not need access to a model's private internal reasoning for this process to be auditable. A useful audit trail records observable tool calls, returned data, selected evidence, and actions taken.
The Research Evidence Graph agent has a bounded task: answer research questions with traceable evidence and prepare proposed graph updates for review when new documents are provided. It is not authorized by default to publish conclusions, alter source files, or make external commitments. Defining that scope allows the tool interface and evaluation to focus on concrete behavior. It also makes failure recovery easier because the system knows which actions were legitimate parts of the task.
11.2 Graphs as agent memory
Agent memory（智能体记忆）can be divided by function. Episodic memory（情景记忆）records interactions and events. Semantic memory（语义记忆）stores relatively stable concepts and facts. Procedural memory（程序性记忆）stores reusable methods or workflows. A graph can link these forms without making them interchangeable. A record that the user once asked about a topic is an interaction event; it is not proof that the user has a permanent preference or that a scientific claim about the topic is true.
Memory should include provenance, time, scope, and correction mechanisms. A preference inferred from behavior should be distinguishable from an explicit user instruction. A temporary task constraint should not become a permanent global rule. In a multi user environment, memory also needs an owner and access policy. Graph links can make cross task retrieval powerful, but they can also spread an incorrect or unauthorized inference farther than a simple isolated note would.
The proposed memory model stores user approved preferences separately from extracted domain claims and execution logs. Retrieval selects the relevant memory type for the current task. If an agent needs a writing preference, it does not search scientific evidence as though the two were equivalent. If a user corrects a preference, the system updates the active record and preserves enough history to explain the change. This design keeps personalization interpretable.
11.3 Graph guided planning and exploration
Think-on-Graph treats a language model as an agent that explores a knowledge graph and searches for promising reasoning paths [37]. Reasoning on Graphs separates planning, retrieval, and reasoning around graph grounded relation paths [38]. These methods demonstrate ways to use explicit graph structure during question answering. Their reported benchmark results apply to their experimental settings; they do not establish unrestricted reliability for arbitrary organizational graphs or action taking agents.
A practical planner can use a schema to propose a sequence of typed operations. For the question “Which accepted claims depend on the corrected dataset version?”, it can resolve the dataset, traverse dependency links, filter claim status, and retrieve source evidence. The system can verify each operation against a tool contract. If the requested relation does not exist, the planner should revise the plan or explain the gap rather than generating a query against an imagined schema.
Graph exploration should be bounded by depth, number of results, time, and cost. Without bounds, a high degree node can cause a large expansion that adds little relevant information. A stopping rule should depend on evidence sufficiency and task requirements. The agent can stop when it has the required sources, when additional retrieval produces no useful evidence, or when it reaches a budget. Stopping because an answer sounds fluent is not a reliable evidence criterion.
11.4 Typed tools and controlled execution
A typed tool（类型化工具）accepts structured arguments and returns a defined result. Instead of exposing unrestricted database commands to every agent step, the proposed interface includes operations such as resolve_entity, get_claim_evidence, find_dependencies, and propose_assertion. These names describe application capabilities, not a requirement for a particular framework. A tool implementation can use Cypher, SPARQL, or another backend while enforcing the same contract.
For exploratory analysts, a controlled query tool may still be appropriate. It should distinguish read operations from writes, validate the query structure, bind parameters, enforce timeouts, and restrict accessible procedures. Read only should be enforced by the execution environment or database role where possible, rather than by asking the model to promise not to write. The tool response should also identify truncation so the agent does not mistake a result limit for complete coverage.
Write operations need stronger contracts because they change future knowledge. A proposed assertion should contain canonical arguments, relation type, evidence, qualifiers, and expected graph version. Validation can then check whether the write is admissible and whether the underlying state changed since the proposal was prepared. An idempotency key prevents a retried request from duplicating the record. These controls support reliable automation without requiring a human to supervise every harmless read.
A proposed agent architecture separating authorized tasks, read tools, evidence, and validated writes. The observe loop supports plan revision.
Original figures retain bilingual labels. Read alongside the explanation; open for a larger view.11.5 Evidence is not an instruction channel
Documents and graph properties can contain text that looks like an instruction. A retrieved passage might say “ignore previous rules” or request that the system send data elsewhere. In a research workflow, that text is source content to be analyzed, not authority over the agent. The execution layer should preserve this boundary. A graph does not eliminate prompt injection（提示注入）risk if untrusted text is later inserted into a model context without distinguishing data from authorized instructions.
The proposed agent labels tool outputs by origin and uses only the user's authorized task and system policy to choose actions. It can quote or summarize instructions found in a document when they are relevant to the research question, but it does not execute them merely because they appear in retrieved evidence. This is especially important for write tools and external services. Provenance helps identify where content came from; permission checks determine what the agent may do with it.
11.6 Planning knowledge and action authority
A graph can describe possible actions, prerequisites, and expected effects. For example, a workflow graph may state that a dataset must be validated before an analysis is released. The agent can use that information to plan. The action service must still verify the actual current prerequisite before executing the release. A stored statement that validation occurred may be outdated, and the agent's retrieved snapshot may lag behind the operational system.
This separation addresses a common design weakness: treating a semantic relationship such as CAN_APPROVE as sufficient authorization. The graph may help discover the relevant role, but the authoritative permission system should decide whether the current actor can perform the action. Similarly, a path showing that a user belongs to a team is not enough if membership expired or if the permission applies only to a different project. Time, scope, and policy version must be evaluated at execution.
11.7 Recovery learning and multiple agents
An agent should record the state needed to recover from a failed operation. If retrieval times out, it can retry a bounded read. If a write response is lost, it should check the idempotency key before repeating the write. If the schema changes during a task, it should reload the relevant contract. Recovery behavior is easier to test when actions have explicit preconditions and results rather than being embedded in long free form scripts.
Several agents may share a knowledge graph, but shared storage does not guarantee coordination. They may use different snapshots, attach conflicting claims, or duplicate work. A shared task record can identify ownership, status, and accepted outputs. Optimistic concurrency checks can detect stale updates, while provenance identifies which agent produced a candidate. A human or deterministic policy may still be needed to resolve semantic conflicts. Agreement among several models is not independent empirical confirmation when they share sources and assumptions.
Learning from interaction should be selective. Successful completion of one task does not establish that every intermediate inference was correct. The system can retain verified corrections, reusable tool outcomes, and user approved preferences while leaving speculative reasoning outside persistent factual memory. This prevents a temporary mistake from becoming a trusted premise in later tasks. Memory quality should be evaluated over sequences of tasks, where accumulation and correction effects become visible.
11.8 Recent directions and deployment criteria
Think-on-Graph 2.0 investigates graph guided retrieval with richer information access [44]. Youtu-GraphRAG proposes a more integrated agentic approach linking graph construction and retrieval [43]. These are useful examples of research directions, but this report cites their identifiable preprint records and does not treat their performance claims as independently reproduced results. Their main relevance here is architectural: construction, schema, retrieval, and reasoning increasingly interact rather than operating as isolated modules.
An agent should be deployed only at the level of autonomy supported by task specific evaluation. A research assistant that reliably retrieves evidence may still be poor at updating a canonical graph. A system that writes valid records may still be unfit to publish conclusions automatically. Evaluation should distinguish read quality, planning quality, update quality, permission compliance, and recovery. The knowledge graph can make these dimensions observable, provided that the design preserves the status and origin of every consequential piece of information.