TCL

1. 介绍一下你做的这个代码助手 Agent 项目2. 你这是在网上找的项目 还是哪里学的3. 状态机是用于干什么的状态机在 Agent 里最重要的作用，是把模型原本“想到哪做到哪”的行为，变成一个可观察、可控制的执行流程。特别是代码助手、文件助手、自动化办公这类场景，如果没有状态机，模型一旦中途拿到错误信息或者误判上下文，后面就可能一路错下去。用了状态机之后，你可以明确规定当前是分析态、规划态、确认态、执行态还是回滚态，每个状态允许什么动作，不允许什么动作。我自己的理解是，状态机不是为了让系统显得高级，而是为了收敛复杂性。你要让模型做事情，就不能只靠 prompt 约束，还要靠流程边界约束。...

这种的是真的假的，有没有什么陷阱啊

大四上学期在某厂实习了三个月，说说真实感受吧。进去之前幻想的是参与核心项目、接触前沿技术。实际上每天就是写一些边角需求，改改前人的代码，开不完的会。mentor人挺好但也很忙，大部分时间还是自己摸索。最大的感触是：大厂没有想象中那么光鲜。工位很挤，实习生能接触到的东西真的有限，很多核心代码权限都没有。现在春招我反而没那么执着大厂了，更看重具体做什么、团队氛围怎么样。实习过一次之后你就会发现，公司名字真的只是个壳子，每天干的活才是实实在在的。

有一个问题：Multi-Agent 架构到底适合什么场景？ 很多人第一反应是：“任务复杂的时候就用多 Agent。” 然后面试官就会继续追问：什么叫复杂？复杂体现在哪？引入多 Agent 的代价是什么？有没有明确不该用的场景？ 如果这些问题答不清楚，这道题基本就丢分了。 真正成熟的回答，不是“复杂任务适合拆分”，而是要给出一套可操作的判断框架。结合 Claude Code、Codex 类产品的实战经验，可以把这个问题归结为一句话： 默认先用单 Agent，只有在单 Agent 已经暴露出明显瓶颈时，才引入 Multi-Agent。 好像也是很扯。 为什么不能默认上 Multi-Agent？ 很...