Agent 到底是什么？一个 Java 开发者的认知纠偏

我花了不少时间看一个多 Agent 面试平台的代码，越看越觉得不对劲——Agent 怎么就是数据库里的一行配置？这和我之前看的 LangChain、AutoGPT 完全是两回事。后来才想明白，Agent 有两种形态，而大多数人接触的其实是简化版。

---

目录

• 从一个误会说起
• 一个真实项目里的 5 个 Agent
• 5 步实现一个 Agent
• 星辰大模型：Agent 背后的 AI 引擎
• Facade 协调：Agent 不是自己跑的
• 认知升级：从配置到自主决策
• 系列导航
• 一句话总结

---

从一个误会说起

第一次打开这个面试平台的 Agent 模块，我愣了好几秒。

数据库里存着一张 agent_properties 表，每个 Agent 就是一行：名字、API Key、API Secret、工作流 ID。没了。

SELECT * FROM agent_properties;

id	agent_name	api_key	api_secret	api_flow_id
1	通用智能体	abc123	secret1	flow_001
2	面试出题官	def456	secret2	flow_002
3	用户答案评分官	ghi789	secret3	flow_003
4	神态分析官	jkl012	secret4	flow_004
5	面试提问官	mno345	secret5	flow_005

这就是 Agent？我当时的第一反应是——这不就是配置嘛。几个 key，一个工作流 ID，跟我在博客和论文里看到的 Agent（推理、工具调用、自主决策）差了十万八千里。

后来花了一整天把代码啃完，才搞清楚：Agent 这个词在不同语境下指的是完全不同的东西。

---

一个真实项目里的 5 个 Agent

先说说这个项目是干什么的。

码上面试平台——基于 Spring Boot 3.4 + Java 17 + 星辰大模型的模拟面试系统。用户上传简历，AI 自动出题、提问、评分、追问，最后生成面试报告。

面试这件事在现实里本来就是多人协作的：一个人看简历出题，另一个人负责提问，还有人专门打分。这个项目把这套分工搬到了代码里——每个面试官就是一个 Agent。

现实世界                              代码世界
---------                              --------
出题官 → 看简历，出题目               Agent("面试出题官") → 调 AI → 返回面试题
提问官 → 读题目，问候选人             Agent("面试提问官") → 调 AI → 返回提问内容
评分官 → 听答案，打分数               Agent("用户答案评分官") → 调 AI → 返回分数
追问官 → 看分数，决定要不要追问       Agent("追问官") → 调 AI → 返回是否追问
表情官 → 观察仪态                     Agent("神态分析官") → 调 AI → 返回仪态评分

5 个 Agent 各司其职，通过编排组合起来完成一场完整的模拟面试。后面的文章会专门讲编排模式（Facade、Chain、ReAct），这篇先聚焦一件事：单个 Agent 到底是怎么实现的。

---

5 步实现一个 Agent

这个项目的 Agent 实现分 5 层，从数据库到 API 调用，每层各管一件事。

第 1 步：建表

CREATE TABLE agent_properties (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    agent_name VARCHAR(100) COMMENT '智能体名称',
    api_key VARCHAR(200) COMMENT 'API Key',
    api_secret VARCHAR(200) COMMENT 'API Secret',
    api_flow_id VARCHAR(100) COMMENT '星辰工作流 ID',
    create_time DATETIME,
    del_flag INT DEFAULT 0
);

INSERT INTO agent_properties (agent_name, api_key, api_secret, api_flow_id)
VALUES ('面试出题官', 'abc123', 'secret1', 'flow_002');

第 2 步：实体类

@Data
@TableName("agent_properties")
public class AgentProperties {
    @TableId(type = IdType.AUTO)
    private Long id;
    private String agentName;
    private String apiKey;
    private String apiSecret;
    private String apiFlowId;
    private LocalDateTime createTime;
    private Integer delFlag;
}

第 3 步：场景枚举

public enum BusinessAgentEnum {
    INTERVIEW_QUESTION_GENERATOR("面试出题官"),
    INTERVIEW_QUESTIONER("面试提问官"),
    INTERVIEW_ANSWER_EVALUATOR("用户答案评分官"),
    INTERVIEW_FOLLOWUP("追问官"),
    INTERVIEW_EXPRESSION_ANALYZER("神态分析官");

    private final String agentName;

    BusinessAgentEnum(String agentName) {
        this.agentName = agentName;
    }
}

第 4 步：场景解析器

@Service
public class BusinessAgentResolver {

    private final AgentPropertiesMapper agentPropertiesMapper;

    public AgentProperties resolve(BusinessAgentEnum agentEnum) {
        // 根据场景枚举，从数据库查出对应的 Agent 配置
        return agentPropertiesMapper.selectByAgentName(agentEnum.getAgentName());
    }
}

这是整个设计里最巧妙的地方。业务代码不直接写死调哪个 Agent，而是通过枚举告诉解析器：我需要面试出题官。解析器去数据库查配置，拿到 API Key 和工作流 ID。要换 Agent？改数据库就行，代码不用动。

第 5 步：调用 AI

@Service
public class InterviewWorkflowService {

    private final BusinessAgentResolver resolver;
    private final XingChenAIClient aiClient;

    public InterviewQuestionRespDTO extractInterviewQuestions(InterviewQuestionReqDTO req) {
        // 1. 解析出面试出题官的配置
        AgentProperties agent = resolver.resolve(BusinessAgentEnum.INTERVIEW_QUESTION_GENERATOR);

        // 2. 组装参数，调用星辰大模型
        Map<String, Object> params = buildParams(req);
        String result = aiClient.execute(agent.getApiKey(), agent.getApiSecret(),
                                          agent.getApiFlowId(), params);

        // 3. 解析返回的 JSON，转成 DTO
        return parseResult(result);
    }
}

5 步走完，一个 Agent 就能从数据库配置到实际调用 AI 全链路跑通。整个过程没有推理、没有工具选择、没有自主决策——就是查配置、传参数、调接口、解析结果。

---

星辰大模型：Agent 背后的 AI 引擎

这个项目用的 AI 不是直接调 OpenAI 或 DeepSeek 的 chat 接口，而是星辰大模型的工作流平台。

普通大模型调用是一问一答：你丢一段 Prompt，它回一段文本。但星辰平台不一样，它支持工作流——你可以把多个处理步骤串成一条流水线。

普通大模型调用：
用户输入 → 大模型 → 输出

星辰工作流：
用户输入 → 步骤1：解析简历 → 步骤2：提取技能 → 步骤3：生成面试题 → 步骤4：格式化输出

5 个 Agent 背后实际上是 5 个不同的工作流——出题有出题的流程，评分有评分的流程。每个 Agent 的 api_flow_id 就是它在星辰平台上的流水线编号。

---

Facade 协调：Agent 不是自己跑的

有一个容易忽略的点：Agent 本身不会自己被调用。它需要一个协调员来安排什么时候该找谁。

这个项目用的是 Facade 模式，InterviewSessionFacade 就是那个协调员。

@Service
public class InterviewSessionFacade {

    private final InterviewWorkflowService workflowService;
    private final InterviewSessionService sessionService;
    private final InterviewRecordService recordService;

    public InterviewQuestionRespDTO extractInterviewQuestions(...) {
        // 1. 先告诉会话管理：状态改成上传中
        sessionService.markUploading(sessionId, userId);

        // 2. 调用工作流服务，找到出题官 Agent，调 AI
        InterviewQuestionRespDTO response =
            workflowService.extractInterviewQuestions(req);

        // 3. 搞定了，状态改成准备就绪
        sessionService.markReady(sessionId, userId, ...);

        return response;
    }
}

前端代码只调一行 facade.extractInterviewQuestions()，不用知道里面有状态管理、Agent 解析、AI 调用、结果解析这些步骤。

没有 Facade 的话，前端得自己一步步调：先标状态、再找 Agent、再调 AI、再更新状态。任何一个步骤出错或者顺序变了，前端就得跟着改。Facade 把这些封装起来，前端只管要出题，内部怎么协调它不关心。

类比一下：你找婚礼策划师，策划师去对接酒店、摄影、化妆。你不用挨个打电话。

---

认知升级：从配置到自主决策

回到开头的问题：Agent 到底是什么？

啃完这个项目的代码后，我把自己的认知升级路径整理了一下：

第一层：Agent = 配置。 数据库里存几个 key，代码根据场景找配置、调接口。这就是这个项目在做的事。

第二层：Agent = 配置 + 调用逻辑。 不光有配置，还有 Resolver 做场景匹配、Facade 做流程协调、XingChenAIClient 做 API 调用。配置本身不干活，这些胶水代码才是 Agent 能跑起来的原因。

第三层：Agent = 大模型 + 工具 + 记忆 + 调度。 这是 LangChain、AutoGPT 里说的 Agent——能自己决定调什么工具、记住历史对话、动态调整行为。标准说法是四大组件：推理层（大脑，负责任务拆解和决策判断）、工具执行层（手脚，RAG 检索和 API 调用等外部能力）、记忆模块（短期记忆存对话上下文，长期记忆存历史偏好）、规划编排层（调度中枢，判断任务是否完成、要不要调下一个工具）。这个项目的 Agent 没有这些能力，调谁、传什么参数都是代码写死的。

第四层：Agent = 自主决策系统。 ReAct 模式（Reasoning + Acting：思考→行动→观察→循环）、多轮工具调用、根据中间结果改变策略。这是完整形态的 Agent，但实现成本也最高。

这个面试平台的 Agent 处在第一层和第二层之间。但已经能跑通完整业务了——5 个 Agent 配合起来，完成一场模拟面试没有问题。

那什么时候需要第三层、第四层？当流程不固定的时候。

面试出题→评分→追问，这个流程是固定的，每一步找哪个 Agent、传什么参数，在代码里写得清清楚楚。不需要 AI 自己决定要不要调工具或者该调哪个工具。

但如果你要做一个智能客服——用户说我的订单没发货，Agent 需要自己决定先查订单、再查物流、然后根据结果决定怎么回复——这就需要完整的 Agent 了。流程不是写死的，AI 得自己判断下一步干什么。

大部分业务场景其实不需要完整的 Agent。流程固定、输入输出明确、步骤可预期——简化版就够了。别被网上那些 Agent 革命的文章吓到，觉得不上 ReAct、不接向量数据库就不叫 Agent。

先把简化版跑通，验证业务价值。 如果发现流程经常变化、需要 AI 自己判断，再升级也不迟。

---

系列导航

这是「Agent 架构认知升级手册」系列的第 1 篇，从一个 Java 开发者的视角，走一遍对 Agent 的认知纠偏。

篇	主题	核心问题	状态
1	Agent 到底是什么（本篇）	简化版 vs 标准版 Agent	✅
2	多 Agent 编排实战	Facade、Chain、4 层输出校验	计划中
3	Agent 为什么总是失忆	从数据库到 RAG 的 3 种记忆方案	计划中
4	ReAct、Chain 还是 Facade	Agent 推理模式的选择指南	计划中
5	RAG + Agent vs 纯 RAG	什么时候需要研究助理	计划中

系列阅读路径： 1→2→3→4→5（完整学习路径），每篇也可单独阅读。

关联已发布博客：

• Hermes-Agent 深度解析：记忆机制与自学习设计——Agent 记忆的框架级实践
• PostgreSQL 向量数据库 pgvector：RAG 实战与多场景适配——RAG 基础设施搭建
• Codex 多 Agent 协作开发实战：AIGrader 项目——用 AI 工具开发多 Agent 项目的视角

---

一句话总结

Agent 的核心不是有没有 AI 大脑，而是什么场景 -> 找谁 -> 怎么调 -> 怎么处理结果这条链路能不能跑通。 能跑通，它就是 Agent——哪怕大脑在云端，本地代码只负责调度。