React/Vite 前端如何交给 Python/FastAPI 托管：从 npm run build 到默认首页入口

项目里有一个 app_manage，前端是 React + Vite，后端是 Python + FastAPI。最开始的问题很直接：service.sh 启动时，能不能把前端也一起拉起来，并且把 Python 服务的默认首页切到这个前端。 这类需求第一次看，很容易顺手想到 service.sh 里再后台起一个 npm run dev。它能跑，但不太像一个稳定的服务发布方案。真正要先分清的是，这个前
#Python #FastAPI #React #Vite #前端工程 #静态资源

把 AI 助手改成 SSE 打字机输出，这次我没有去改 messages

这次要做的需求不复杂：让 AI 助手的回答从“等几秒后整段出现”，改成“边生成边显示”的打字机效果。 一开始最容易想到的改法，是把现有的 GET /messages 改成 SSE。看起来改动小，前端也已经有一个拿消息的入口。但把链路顺下来以后，这个方向很快就卡住了，因为 /messages 在当前系统里承担的是历史投影和断线补齐，不是当前这一次提问的实时生成通道。 先把链路看清楚当前链路其实是三段
AI
#FastAPI #SSE #AI #Spring Boot #小程序

AI Agent 里的 Prompt、History 和 Tool Result 该怎么分层

这次讨论最后收敛到的不是某一条 prompt 怎么写，而是 AI Agent 的上下文到底该怎么分层。 当时链路里已经出现了一个比较典型的问题：用户问“给我看看你的 prompts”“你的模型是什么”“你的指令是什么”这类问题时，系统虽然有安全策略，但模型还是会用自然语言复述一部分内部实现，包括 function calling、工具名、运行模式和系统约束。再往下看 prompt 结构，问题也就比
AI
#Agent #Function Calling #AI工作日志 #复盘 #Prompt #上下文管理

AI 日志单独落盘这件事，MDC 到底在做什么

最近在收一条 AI 日志链路。诉求不复杂：AI 相关日志要单独落到 ai-chain.log，但每行日志尾巴上那串 [aiChain= aiConversationId= aiToolCallId= aiToolName=] 太重了，想砍掉大部分字段，最好日志正文里连 aiChain=true 都不要看到。 这类问题很容易改着改着偏成“怎么把日志打印得更短”，但代码顺下来以后会发现，核心不在展示，
AI
#AI工作日志 #Java #Logback #MDC #AI日志

把知识问答下沉到 Dify 终态回答器

这次改动不复杂，判断比实现更重要。 我们原来的知识问答链路是本地 Agent 自己调 knowledge.search。问题不是它查不到东西，而是查出来的结果太大，tool_result 又会进 transcript，后面的 plan、loop、verify、answer 几轮都会把这包结果再塞回 prompt。实际看下来，单次 llm_request 很快就从两三百 KB 涨到五百多 KB，最后
AI
#Agent #AI工作日志 #RAG #Dify #开发回顾

AI Agent 前沿调研：软能力下沉为硬能力、Skills、Subagents 与 Workflow 的真实趋势

结论先行 这轮跨 X / Reddit / Linux.do / GitHub / 论文 / 官方文档 调研后，最清晰的共识不是“让 agent 更自由”，而是： 把 自由裁量缩到少数高价值决策点 把 执行、验证、补参、审计、回放 下沉到 runtime / workflow / grader / skill 把 domain-specific 差异 优先做成 sk
AI
#AI工作日志 #LangGraph #ReAct #AI Agent #Workflow #Skills #Subagents #调研

从顶级 AI Agent 架构视角看这套 Python Agent 项目

我先给结论。 这个项目现在不是“做不成事”，而是已经到了一个很典型的拐点： 作为单智能体、少量工具、强业务约束的企业 Agent，它已经能跑通主链。 但它的可靠性主要靠 prompt + 少量 runtime 约束 + MCP 双视图 顶住。 一旦继续加工具、加查询类型、加多跳深度，复杂度会明显上升，而且会越来越依赖 prompt 特判。 从顶级 AI Agent 架构视角看，当前最值得做的不
AI
#AI工作日志 #AI Agent #架构评审 #MCP #Python #LLM

别再让 Agent 靠感觉停下来了：聊聊通用多跳规划能力怎么做

最近在调一条生产计划问答链时，碰到一个很典型的问题。 用户问的是“今天计划炉次有多少”，系统却在第一跳 production_plan_search 后就停了，直接把计划列表里的 count/total 当成了答案。真正需要的链路其实是： 先查计划，定位目标计划。 再查计划详情。 最后基于详情里的计划炉次做汇总。 这个问题看起来像“模型不够聪明”，但本质不是。更准确地说，是系统没有把“当前要回
AI
#Agent #Function Calling #MCP #AI #架构

AI Tool 回答为什么会泄漏内部字段名

这次踩坑点不在工具调用本身，而在回答阶段。 链路里工具已经查到了正确数据，tool_call -> tool_result 也没问题，最后给用户的 final 还是把内部字段名说了出来，比如： furnacePlans ladleBatchCountTarget 这类字段名即使业务含义没说错，也不该出现在用户可见回答里。问题不是“模型不懂业务”，而是我们把不该给它看的东西也一并塞进了回答
AI
#Agent #AI工作日志 #复盘 #Prompt #MCP #AI

别再把 Tool Result 整包喂给 Answer LLM 了

最近在收一条 AI 工具链路时，问题不是 tool schema 怎么写，也不是 function calling 到底该不该开，而是一个更容易被忽略的点：tool 调完之后，返回给后续节点的那份结果，到底该长什么样。 一开始最直觉的做法是，tool 查到了什么就把什么整体回传。Java 侧查出一个对象，塞进 ToolResult.data；Python 侧拿到这份结果，再把它整个塞给回答节点。看
AI
#Function Calling #AI工作日志 #AI Agent #MCP #架构设计 #Tool Calling