一些关于软件工程、系统设计
AI 使用的记录

写下过程、取舍和复盘,也记录学习新技术的方式

"不要回避不懂的东西,把它弄明白,再做深一点。"

— 工程学习实践

"天下代码一大抄,抄来抄去有提高,看你会抄不会抄。"

— 抄的核心是理解设计和取舍

True Code

Agent 祛魅:回归工程现实

从智能幻想到工程现实:我的 Agent 构建思考与实践记录

Step 01

建立「认知管」

重塑思维模型

刻意搭建一套反直觉但正确的 Agent 工程认知体系,帮助 Java 开发者跳出传统编程范式,理解 Agent 系统设计的底层逻辑。

认知重建范式转换思维升级

Step 02

工程逻辑拆解

六大设计维度

从控制流编排、状态管理、决策边界、知识获取、行动管理到可观测性,全面拆解 Agent 系统的核心工程维度。

控制流与编排模型状态与上下文模型决策与规则边界知识获取与约束行动与副作用管理可观测性与稳定性

Step 03

技术映射原则

工程化落地方法论

将设计维度映射到具体技术实现,涵盖 AgentScope 流程编排、Spring AI RAG、Function Calling、多级记忆系统与 LLMOps 监控。

AgentScope 流程编排Spring AI 进阶 RAGFunction Calling 安全边界Redis + Postgres 多级记忆LLMOps 全链路监控

Step 04

完整系统落地复盘

真实项目实战

通过简历分析 Agent 和辩论机器人 Agent 两个完整系统的搭建,将所学知识串联为可交付的工程成果。

简历分析 Agent辩论机器人 Agent

Engineering Dimensions

六大核心工程维度

系统化拆解 Agent 工程的每一个关键设计维度

控制流与编排模型

LangGraph / 状态机 / 循环

掌握 Agent 编排的核心范式,构建灵活可控的任务流转逻辑

状态与上下文模型

存储 / 记忆 / Session

基于 Redis 与 Postgres 构建多级记忆系统,实现上下文的高效管理

决策与规则边界

LLM vs Rule vs Human

明确 AI 决策与规则驱动、人工干预之间的边界与协作机制

知识获取与约束

RAG / Re-rank

通过 Spring AI 实现进阶 RAG 实践,提升知识检索的准确性与相关性

行动与副作用管理

Tool / Function Calling

深入理解 Function Calling 的工作原理与安全边界设计

可观测性与稳定性

性能 / Tracing / 纠错

在 Spring Boot 中落地 LLMOps,构建全链路监控与异常追踪体系

What You'll Unlock你将解锁什么

[祛魅]
Agent 并不是智能体,而是 LLM 参与决策的业务系统

当一个概念开始被反复拟人化、神秘化、营销化,它往往已经偏离了工程事实。

+Build an financial analytics dashboard
</>
Design
{ }
Image
Code
Deploy

Agent 并不是一种新的系统形态,它只是一次决策方式的工程升级。

大量文章、视频、演讲不断强调:Agent 会成长、Agent 有人格、Agent 能自我反思、Agent 像人一样工作、协作、进化。这些说法听起来令人兴奋,也极具传播力。

[01]
Agent 看起来会思考,其实只是你在维护一个 while 循环

“多步推理”是工程分段,不是意识层级;“自我反思”是最成功的一次命名误导

U
Design a modern portfolio page
AI
AI Agent
Let's start by creating a React application.
~/Desktop/project
npx create-react-app portfolio
./app/page.tsx+195-0Review

Agent 做不到。这不是哲学判断,是工程事实。 如果 Agent 真的会“反思”,系统将无法上线;

Agent既不能决定是否继续运行,也不能突破你写下的控制逻辑。

[02]
Agent 没有长期记忆,只有你设计的数据检索策略

如果一个系统真的有记忆,那它至少应该在不被提醒的情况下,主动使用过去的信息。

page.tsx
1export defaultfunction Page() {
2return (
3<main>
4<Hero />
5<Features />
6</main>
7)
8}

记忆必须是持久的、可累积的、并且会自动影响未来决策。而 Agent 一个条件都不满足。

LLM 天生不可能拥有记忆,这是一个物理级别的事实,而不是设计缺陷。

Project Context
src/
components/analyzing...
hooks/
lib/
Found 12 components, 5 hooks, 3 utilities

Agent 并不是来取代工程系统的,而是用来处理规则系统最痛苦的部分,Agent 是“模糊规则”的执行器。

如果你把 Agent 的定义抽象到最低层,根据输入状态选择下一步动作,并驱动系统执行.那么你会发现:工作流引擎、规则引擎、决策树、状态机本质上全都是 Agent

[04]
当你把 Agent 当成业务系统,而不是“智能体”,一切都顺了

所有混乱,都始于一个错误的心智模型,Agent 项目之所以容易失控,并不是因为 LLM 太复杂,而是因为:人们在“怎么想它”这一步就想错了。

page.tsx
1export defaultfunction Page() {
2return (
3<main>
4<Hero />
5<Features />
6</main>
7)
8}

一旦你做一个非常简单的认知替换:Agent = 一个不稳定、但有价值的业务组件,事情立刻开始变顺。

不再试图:模拟人类智能、复刻人类思考、设计“人格”,你只是在做一件非常工程化的事:用概率判断,替换掉最痛苦的规则维护区。从“智能体崇拜”回到“系统责任制”

[05]
Agent 工程的终局形态:弱智能 + 强系统 + 人类兜底

如果我们不再神话 Agent,它到底该怎么用?

Project Context
src/
components/analyzing...
hooks/
lib/
Found 12 components, 5 hooks, 3 utilities

一个反高潮的结论:弱智能,反而更安全

这是很多人最不愿意接受的一点。但工程上必须直说:有些责任,系统不能承担。Agent 只能“辅助”,不能“负责”。