Notes
The main reason we used agno back then was to get agent functionality: actually our tech plan didn’t have this at first, the earliest idea was plain prompt engineering plus a ragflow-based knowledge base but then the client changed the requirements out of nowhere and asked for more complicated lookup and storage, and after talking it over we found agent was the only way to do it, because it involves multi-turn queries plus summarizing, and a plain knowledge base is nowhere near enough we tried langchan at first but ruled it out, too heavyweight, then picked agno since it deploys lighter, and started writing agno’s most obvious advantage is that it’s simple, import it and you can deploy fast, so the architecture we ended up with was agno + tool call to hit the ragflow knowledge base, whose sdk support is good
Technically, the concrete backend implementation goes like this: first the user sends a request, then we build the template prompt, which contains the user info sent from the frontend: their name, id, and role, plus the permission scope that comes with it, and if the user uploaded a file, the file’s name and format too once that’s handled, the prompt goes over to the agent side, and from there it gets dealt with by the agent and the mcp tools the main special consideration for auth in an Agent setup is stating it explicitly in the prompt, the frontend just has to wrap things properly and confirm the role coming in is correct, then there isn’t much to think about here, just split by role
Collaboration ran mostly on github project for settling the task list, plus Tencent Meeting (similar to zoom) and qq (because the engineers working with me were in China). Keeping progress in sync relied mostly on the todo items and regular meetings. Every meeting went over current progress, what was moving on the client’s side, and whether we’d hit technical problems, and if so how to solve them.
The hardest part of the whole thing, I think, was that the senior engineer working with me picked a toolchain he wasn’t familiar with himself, especially nest.js, a package I had never touched before. My approach was to learn it, read the official docs first, then have ai work alongside me. Since unfamiliar tech was involved I was very careful to make it explain everything down to the last detail (why do it this way, the reasoning has to hold up), and once I was roughly comfortable I started thinking it through and building on my own. the boilerplate comes from official tooling, and every one of them is clearly defined, so I only have to fill in the relevant functionality. nest’s backend modules are very cleanly separated,
microservice architecture dify
autogen, can do multi-agent dialogue, group chat too, plus adding human feedback partway through, agno doesn’t have this
HippoRAG, a brain-like rag framework
hono/client microservice architecture, but strict about return
The biggest thing I felt from collaborating is that the senior engineer I was paired with is also mostly vibe, but his thinking and design stay firmly human-led
when vibe coding, the prompt gets specific down to which file and which function to change nocobase is badass, it can cover the whole frontend, a startup near me uses it for supply chain management, has been for over two years if you want a backend with the wordpress experience you can use strapi, the open source one is enough ant design pro domestically, mui toolpad core overseas reactflow, the industry standard drag component logseq has a very strong style, what they’ve made doesn’t even look like markdown anymore
agno ran into problems later, couldn’t query the database, couldn’t connect to the vector db at all, anything carrying a session broke, so we switched to mastra, agno’s biggest problem is that its documentation support is very incomplete.
I think treating the interview as process-oriented is enough, talked with an executive for an hour and a half, and even without an offer you get to learn some things about the industry
- a fair number of government tenders are in old languages, and that’s where fast learning and AI skills come in
- the demand for document processing is there, but they lean toward phased rollout, overly aggressive technical experiments don’t suit government clients
- focus on your own past experience, for education a rough explanation is enough, since they sent the interview invite it means that part isn’t the point
- a lot of old-language architecture is maintenance, and the naming standards are bad, but the core logic is procedural so it’s relatively less hard, the main thing is working out what it’s doing
- you can adjust the salary up within reason, then say you can accept the base early on, the point is trusting the company will adjust by evaluating ability, gives them a way out
- when talking about AI, tie it more to the places AI can improve efficiency, you can emphasize a senior engineer’s high-granularity vibe, then pull it back to human-led
- you can emphasize being able to pick things up fast even when you’re not familiar with them, caring about first principles at the essential level, reasoning from what software engineering has in common, and the rest is really just getting familiar with how things are written across languages and the specific tools
- emphasize your multi-language orientation, though this depends on what position you’re interviewing for, if it’s a specialist one this strategy won’t work and you have to push in a direction that fits
Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: 记录.